[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Application support for ODF metadata model
Hi all, Patrick & I were having an interesting conversation off-list about how applications, including OpenOffice, might wish to implement support for the metadata model -- in particular the more heavyweight (separate RDF files, non-inline) metadata mechanism. Let's bracket out the question of how the metadata gets entered in the first place -- an interesting and critical question, but not the point of this post. For now, let's stipulate that we've established an mechanisms that allow the document-editing app (let's assume OpenOffice [OO] for discussion purposes), to construct one or more RDF graphs (in some form, not necessarily fully valid RDF-XML) in memory during a document edit session, based on user input provided in some fashion. Then, at some point during a document edit session, there is going to arise the question of how and under what triggering circumstances OO should: (1) persist this RDF by fully serializing it out into fully valid RDF- XML with all the correct headers and such, and writing it out into the on-disk ODF document file. (2) whether the RDF graph should be split into multiple named graphs (files), or should be a single RDF file. (3) also, the app will need at that point to update the RDF manifest, to the extent required; and (4) it may need to decide whether some assertions need to be relocated into the manifest rather than reposited in one of the RDF data files. (This would be the case for assertions that the author had indicated he/she wanted to fully expose by placing into the manifest--which I view as the publicly-exposed RDF portal into the document's metadata.) There is, naturally, a scope question here. You could argue that these kinds of implementation questions are out-of-scope for the metadata group. On the other hand, I do see these questions as relevant to fundamental issues of metadata ownership, metadata authorship, metadata disavowability, etc. That's because we're talking here basically about some notion of "submitting" or "accepting" the metadata. There's some analogy to the mechanism in OO for accepting/ rejecting proposed edit changes in a multi-user document. There's also some analogy to the notion of "submitting" a form-based document. How you understand these things is part of how you define what metadata is. So does anybody have any comments, in particular, about what the triggers might be that would appropriately cause the app to persist out the metadata? Persist the metadata on any save operation? Have a special button so the author can flush the metadata, and only do it on specific command of the user? Do it when the document receives and electronic signature? Maintain separate metadata files in the background for every different edit session, and then make the author inspect and choose among them in a special operation? Any comments welcome. John
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]