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