Re: [office-metadata] Binding proposal

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

All,

I didn't have the time to follow your discussions, but I would like to 
share my thoughts on this with you anyway.


Bruce D'Arcus wrote:
> 
> On Mar 20, 2007, at 6:19 AM, Svante Schubert wrote:
> 
>>> But you're not solving the problem: you're avoiding it. Using 
>>> "odf:.." as you propose is functionally the same as using "file:///..."
>> The odf: would only refer into the same ODF package, it is not 
>> relative to the document location, by this different to file://
> 
> But what's the identity of "the package"? That's what we need to define, 
> and it needs to be stable and globally unique.

I agree that documents need a stable and globally unique id (or IRI - 
I'm using the term id here only, but it could be any kind of identifier, 
including an IRI) if they contain metadata that have a meaning even if 
viewed outside the document that contains the metadata.

But I'm also wondering whether this is the case for all metadata that 
one may add to a document. If I'm adding a note to a document using 
metadata, does this note have a meaning outside the document it is 
contained in? I don't think so. And if I'm creating a document that I 
store on my hard disk and that I never want to make available to someone 
else (maybe because it contains confidential data), I probably also 
never want to share the metadata in the document.

I further share the concerns that we, if we require that all documents 
get a unique id and if this id is stored in the document, very soon run 
into the situation that this ids are not really unique any more. Simply, 
because we cannot control what happens to documents, and because not 
everyone who uses ODF is aware of the rules we may have regarding these 
ids. I further see the risk that even the metadata contained in 
documents where the ids have been maintained properly are not of use, 
because we cannot differ them from those there this is not the case.

So, it is a dilemma. On the hand, we need stable and unique ids to be 
able to share metadata. And on the other hand, we cannot ensure that 
these ids are maintained properly, but need the help from our users, 
that again have to understand what the id is for.

So, to get out of this dilemma I would like to suggest is we make the 
use of global and unique ids optional. That is, the user itself may 
decide whether she or he want to share the metadata in the document. If 
the user wants to share the metadata, then the document gets a unique 
id, and the user itself is responsible for making sure that the document 
is only edited by applications (or users) that are aware of the id and 
understand what it is about. Of cause, office application may and should 
assist the user in maintaining the id.

If the user does not want to share the metadata, then the document does 
not get an id, and the metadata in the document does not get a meaning 
outside the scope of the document.

In practice, I could image that office applications ask the user whether 
metadata should be shared with others every time a document is saved, or 
that there is a menu item that allows to publish the metadata. In both 
cases, an unique id would be added to document.

Maybe this suggestion is useful.

Best regards

Michael

> 
>> Bruce, maybe we should not try to solve the problem of document 
>> identification in the document as there are risks we can not control: 
>> Some XSLT / webapplication / ODF application might not exchange the 
>> revision ID, but the document.
>> Why should we burden the identification effort to an ODF application, 
>> when in the end a guaranteed identification would be made from the 
>> outside?
> 
> I disagree with "made from the outside" part. I'd say we can defer to 
> the user perhaps (it's up to the user to change the URI for the document 
> if they do a CP), but the identity of a document is fundamental thing.
> 
>> What do we really gain? The UUID tells nothing about the document type 
>> nor the location. Whenever we analyze the metadata of a document, I am 
>> sure we would rather have a link to the document or could use some 
>> more verbose identification mechanism as sender/time/etc.
> 
> Good question: what do we lose if we don't get this right? We lose the 
> ability to reliably define an ODF document or document fragment as an 
> object of a triple. This means we cannot do the following with any 
> reliability:
> 
>     - defining relations among documents (I say this document is a part 
> of that document, and so forth)
>     - annotating documents externally (Rob's "extrinsic metadata" use case)
> 
> ... no doubt the list could be much longer.
> 
>> Is the introduced complexity really worth it's gain?
> 
> I don't think we should cripple the identification scheme just to 
> account for the cp scenario. I think at minimum the document needs a URI 
> that can serve as the base, and that we recommend urn:uuids as a very 
> good fallback (if user doesn't define there own URI, use a urn:uuid).
> 
> I don't like the file:/// and odf: options for the reasons I've outlined 
> before (they are either not stable, or not unique).
> 
> Bruce
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering