Right now in Inkscape and OCAL graphics files meta-data is file wide, yet how can we maintain meta-data for discrete objects and groups of objects?
How can we have both the General/Abstract meta-data and then have specific meta-data for discrete items and groups?
I wonder how we can have it so that when an object or collection of objects is copied and pasted, imported and transformed, that its specific meta-data (beyond specified graphics attributes) can be copied along with itself (making a media object). In the future this will be vital for algorithmic composition of graphics.
Thoughts?
Jon
On Sat, Jul 03, 2004 at 08:40:07PM -0700, Jon Phillips wrote:
How can we have both the General/Abstract meta-data and then have specific meta-data for discrete items and groups?
Well, I suspect we'd need an "RDF Browser" of some kind, sort of like Inkscape's "XML Editor".
For now, I just want to get the "General" RDF editor working. :)
I wonder how we can have it so that when an object or collection of objects is copied and pasted, imported and transformed, that its specific meta-data (beyond specified graphics attributes) can be copied along with itself (making a media object). In the future this will be vital for algorithmic composition of graphics.
You could test for clashing licenses! Hah.
Thoughts?
I'd need to read a lot more about RDF itself. For example, how do we reference a specific SVG group or shape within the doc?
On Sat, 3 Jul 2004, Kees Cook wrote:
On Sat, Jul 03, 2004 at 08:40:07PM -0700, Jon Phillips wrote:
How can we have both the General/Abstract meta-data and then have specific meta-data for discrete items and groups?
Well, I suspect we'd need an "RDF Browser" of some kind, sort of like Inkscape's "XML Editor".
Perhaps you'd just take advantage of XML's natural nesting capability, and do something like...
<g> <metadata> <rdf> ... </rdf> </metadata> <circle ... /> <rect ... /> <text ... /> </g>
but I don't know what the rules are with metadata, and if multiple <metadata> items per doc is allowed (I would assume it is). Certainly will introduce some complexities for our parsers...
For now, I just want to get the "General" RDF editor working. :)
*Nod* Agreed - this will take care of 99% of the cases; the last 1% will be more challenging.
Bryce
On Sat, 2004-07-03 at 23:40, Jon Phillips wrote:
Right now in Inkscape and OCAL graphics files meta-data is file wide, yet how can we maintain meta-data for discrete objects and groups of objects?
If you want to include RDF statements about e.g. a rect with the ID "rect321", you simply use rdf:about="#rect321" on those RDF statements that describe it to make that XML node the subject.
[ rdf:about="" is used to indicate the current document as a whole as a subject, though I am not 100% sure that is correct usage ]
If you want (this is not required -- RDF is not context-sensitive at all), you can make a separate RDF block and put it in a <metadata> child of the object/group/whatever.
(It might be more managable to keep all our RDF in one place in the document to the degree we can help it though, and I don't think we shouldn't move pre-existing RDF around though except perhaps when modifying it.)
I wonder how we can have it so that when an object or collection of objects is copied and pasted, imported and transformed, that its specific meta-data (beyond specified graphics attributes) can be copied along with itself (making a media object). In the future this will be vital for algorithmic composition of graphics.
As you may know, conceptually, all available RDF statements exist as an amorphous pool of (subject, predicate, object) triples.
All we really need is an API for things like "give me a list of RDF triples in this document describing this subject (i.e. an SVG object)" and "merge this list of triples into this document".
-mental
On Sun, 4 Jul 2004, MenTaLguY wrote:
(It might be more managable to keep all our RDF in one place in the document to the degree we can help it though, and I don't think we shouldn't move pre-existing RDF around though except perhaps when modifying it.)
Well, one thought is that as people cut and paste clipart images from document to document, if we wish to preserve the license/authorship info for that element, then it may be more manageable for it to be associated with the given group of elements.
On the other hand, another thought is that the RDF does tend to add bloat, so if the user were to cut and paste 10 copies of the item into the document, and thus added 10 copies of the same RDF to the document, that would bloat the file unnecessarily (even though it would compress well).
I wonder how we can have it so that when an object or collection of objects is copied and pasted, imported and transformed, that its specific meta-data (beyond specified graphics attributes) can be copied along with itself (making a media object). In the future this will be vital for algorithmic composition of graphics.
As you may know, conceptually, all available RDF statements exist as an amorphous pool of (subject, predicate, object) triples.
All we really need is an API for things like "give me a list of RDF triples in this document describing this subject (i.e. an SVG object)" and "merge this list of triples into this document".
Mmm, imagine an RDF editor that displayed all the tagged items in the document, listing author, revision number, etc. etc. For instance, if you're creating a publication composed of works from several other artists/companies, and integrating them in Inkscape, this could offer a nice way of tracking each piece of the document.
Bryce
participants (4)
-
Bryce Harrington -
Jon Phillips -
Kees Cook -
MenTaLguY