Binding by RDF vocabulary for ODF

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

We decided in our meeting to follow Elias' proposal of establishing the 
in-content binding between ODF elements and RDF/XML using a ODF specific 
RDF vocabulary.
Instead of giving a informative proposal about the IRI being used (docID 
vs. odf:/), forcing the RDF application to parse the ID, the binding is 
done by RDF statements.

Svante Schubert wrote:
> [Wed:16:43:18] <EliasT> meta:about="urn:uuid:123"
> [Wed:16:43:32] <EliasT> urn:uuid:123 a odf:Element ;
> [Wed:16:51:32] <EliasT> urn:uuid:123 odf:name "content.xml#foo" .
> [Wed:16:53:47] <EliasT> 1. xml:id
> [Wed:16:54:02] <EliasT> 2. meta:about to always an absolute URI
> [Wed:16:55:44] <flr> eliast: "encourage" programs to generate unique 
> URIs across documents
Before we can specify the ODF specific vocabulary in our proposal some 
thoughts about this:

Although odf:Element is the only ODF resource capable of bearing a 
xml:id to be referenced, it is thinkable that even file resources stored 
in the package are being described.
A superclass might be introduced as odf:Resource. But some may say that 
all relevant resources would be mentioned indirectly by an ODF XML 
element and file names as images might change there names, therefore I 
do not insist in introducing this for this version.

We further have to keep in mind that odf:name is rather the package path 
than the name, because the xml:id being pointed at, is only unique for a 
single xml file of the package.
Multiple xml files with identical names and ids therefore need to be 
distinguished by the package path.

During a transition from package to flat xml, references to xml:ids will 
always require some effort. All xml package files become one and all 
xml:id still have to be unique, although handled by multiple 
applications (e.g. plug-in). A solution would be to change the package 
id during a transformation from package to flat to the package file path 
plus id, to allow a consistent round-trip.

The above set is extensible, further odf properties are imaginable.
For instance, how do we make clear, that we refer to a paragraph in a 
different package, using odf:Document and odf:id.
odf:Document odf:id  tag:odf:550e8400-e29b-41d4-a716-446655440000 .

The remote location might be as well some useful information, but I 
assume there should be already some RDF property.

Svante.