Re: [office-metadata] Application support for ODF metadata model

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hi John,

Interesting topic!

Let's assume that there are only metadata extensions, that will add 
metadata to the document.
There might be extensions working on predefined set of RDF vocabulary, 
e.g. bibliographic extension or some generic extensions that allow to 
load external RDF vocabulary to be used from the user to annotate to the 
content and document. Even extensions to add RDF statements by hand are 
imaginable or extensions that are provide content tagging based on a RDF 
vocabulary describing tags.

In any case the ODF application will surely take control over the 
metadata manifest as there have to be one instance managing all 
extensions, invoking the correct bibliographic extension if a 
text:meta-field of a citation is tried to be edited.

John F. Madden, MD, PhD wrote:
> 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.
Why should the persistence of RDF be in general different as the 
persistence of content or styles?
Saving to package, like auto saving, means to me creating the complete 
package, even if this would mean saving only the parts which have changed.

BTW best thing to reuse exisiting opensource RDF tools for the basic 
RDF/XML handling.
>
> (2) whether the RDF graph should be split into multiple named graphs 
> (files), or should be a single RDF file.
One extension can decide how to split it's RDF graph.

Certainly it might not be desireable to move all data of similar 
vocabularies together.
For example, if the bibliographic extensions would use VCard RDF 
vocabulary and my Customer-list extension would use VCard RDF 
vocabulary, I might find all over sudden Julius Caesar among my customers.
Extensions will have their own named RDF graphs, their data set of 
RDF/XML files, to work and rely on.
>
> (3) also, the app will need at that point to update the RDF manifest, 
> to the extent required; and
The metadata manifest is like a mapping table being saved by the 
managing instance, usually the ODF application itself.
Instead of reading the old and merging with the new, overwriting seems 
easier at this point.
>
> (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.)
The RDF manifest should be for content ID/PATH to RDF IRI mapping and 
RDF file description only, although user RDF statements can be stored 
they should describe solely the RDF files.

>
> 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, 
I assume this will be most likely a desired feature...
> and only do it on specific command of the user? 
> Do it when the document receives and electronic signature? 
Our customer will tell us what to do, let us be customer driven! ;-)
> 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
>
>
Have a nice week-end,
Svante
>
>