Re: [office-metadata] Binding proposal

[Elias Torres <eliast@us.ibm.com>]

Svante.Schubert@Sun.COM wrote on 03/20/2007 07:19:02 AM:

> Bruce D'Arcus wrote:
> >
> > On Mar 19, 2007, at 6:18 PM, Svante Schubert wrote:
> >
> >> Bruce D'Arcus wrote:
> >>>> I would not request UUID as uniqueness is known to be fragile.
> >>> Do you have a source for this claim? AFAIK, the UUID scheme is
> >>> widely implemented in software, and is quite reliable. MS uses it,
> >>> as but one example.
> >> UUID in the context of a document, to express the uniqueness off a
> >> document is fragile, when the document can simply be copied and the
> >> UUID is no longer unique.
> >> UUID in the context of software interface is a nice thing. There is
> >> no interface copy command in software environments.
> >
> > 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://
>
> 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?
>
> 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.

I think the problem started when we began talking about xml:id, meta:about
and using relative URIs. Remember Florian did not like URIs that were based
on file paths? The reason why we started using UUID was because we wanted
to help the plugins mint globally unique URIs that were somehow related to
the document.

docUUID = 123 + element with xml:id=foo = meta:about="urn:tag:123:foo"

Basically, I'm advocating people mint an absolute URI everytime they want
to refer to something and not on the basic "content.xml#foo" relative URI
because of the problems I foresee with it in the RDF/XML future.

I'm with you that if this approach does not solve the cp problem, we should
ignore that. I think it's a perfectly fine approach. Let me explain:


If I today use: <http://torrez.us/who#elias> foaf:homePage
<http://torrez.us>

and somebody (cough cough, Bruce) somewhere says:

<http://torrez.us/who#elias> foaf:name "Bruce D'Arcus" .

I can't stop people using the URI. Therefore a UUID like anything else can
be re-used, what matters is the source of the triples. Therefore, if an
application is dealing with a specific ODF file in a workflow system, it'll
trust whatever is in that file because it trusts the author who uploaded
it. Plain and simple.

Anyways, I just want to make sure we don't throw the baby with the
bathwater and forget we were originally in the process of eliminating
"relative" URIs so our statements work across both zip and flat file
format.

-Elias

>
> Is the introduced complexity really worth it's gain?
>
> Svante