Re: [office-metadata] Differences of our binding/identifications propsals, possible settlement

["Bruce D'Arcus" <bdarcus@gmail.com>]

On Mar 20, 2007, at 11:05 AM, Svante Schubert wrote:

> It seems the differences between our proposals is are not that large.

Yeah, and I just had an epiphany that this might be easier than we  
think ...

> The reason is we won't define in our spec, how to refer to a remote  
> document, anyway. It is up to the user / plugin, which IRI is being  
> used.
> The remote document can be described by a created ID as you suggested
>    tag:odf:550e8400-e29b-41d4-a716-446655440000:6B29FC40-CA47-1067- 
> B31D-00DD010662DA
> or a URL pointing to the document or any other IRI.
> I assume that the ID is only being used, when the document is  
> final, otherwise the relation would broken too easily.
> It seems reasonable to suggest a common naming schema in an  
> informative section.

Actually, the idea I had that simplifies this is the following:

The version-id would *not* be used for subject URIs within graphs.  
They would only -- and optionally -- be used for named graphs where  
come application or plug-in needed to version-control its metadata.

That gives us a stable and unique (apart from the cp scenario, which  
we cannot control) ID for the document, and yet versioning can still  
work.

> The following further differences we had in our proposals:
>
> - The type of the IDs, you recommend twice a UUID, I would rather  
> use an IRI and a integer, is it fine to agree on two strings and  
> suggest UUID informative?
>   By this the URI as document ID with version as integer suffix  
> would be still possible.
>
> - If I understand it right, you want to refer to internal IDs as  
> well by
> tag:odf:550e8400-e29b-41d4-a716-446655440000:6B29FC40-CA47-1067- 
> B31D-00DD010662DA/content.xml#foo
> I suggest to facilitate this by exchanging the prefix for the  
> internal resources of a package by odf:.
> Imagine someone have to exchange all IDs, when the document is  
> being changed and saved. The ODF application does not want to mess  
> with RDF application data.

Right, but if we don't worry about the version-id as above, this  
becomes a non-problem.

> If someone parses the RDF data for external use, the prefix might  
> be exchanged by some IDs (e.g. as you suggested) or a path/local  
> URL. Leave it to the them.
> This would give us flexibility. If someone likes to argue that is  
> not standard procedure, we can say it will become standard, similar  
> as our ODF RDFa elements.
>
> Does this help?
> Svante
>
>
>
>