Application support for ODF metadata model

["John F. Madden, MD, PhD" <john.madden@duke.edu>]

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