Re: [office-metadata] suggestions on identifying nodes, namespace

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

On Feb 22, 2007, at 1:26 PM, Svante Schubert wrote:

> For me the ID with it's binding mechanism is the most important  
> thing to decide.

Agreed.

> I would even separate the usage of a meta:class attribute from this  
> discussion,

Yes, absolutely. The only reason I brought it up is to show that it  
*is* a separate issue.

And the only reason I brought up meta:class earlier is that I was  
assumining a document node that had such an attribute but no about  
attribute in essence creates a blank node. Elias said that's not the  
case in RDFa.

In short, let's forget about meta:class (at least now).

> as Elias stated in the call grouping might be done in RDF/XML group/ 
> bag and is therefore - although possibly welcome - an additional  
> option.

Wait, wait, wait: I just want to clarify that Elias was not in any  
way referring to bags. He was just saying that adding an rdf:type to  
a resource is a way to assign it a class, and so to assign it common  
properties. The solution to the problem you guys were raising was  
rdf:type.

> For now I would like to give examples why I think a unique ID is  
> necessary:
> Imagine there are dozen identical tables in a document. In our  
> earlier scenario we would have given them the same meta:id. But  
> when any RDF application later during the existence of the  
> document, wants to add metadata only to one of the tables (for  
> example to add a running / counting number or to express the one,  
> that is first seen by the reader) there would be no way, but to  
> change the ID, which would raise consistency problems, possibly  
> even unsolvable from the application as it would be linked from  
> external documents.

You have ten tables. They are ten discrete objects, each with  
separate IDs, that can be separately described. We can even use their  
name attributes presumably to construct IRIs for them.

To give them common properties, assign them an rdf:type.

This is what we are saying when we say you are mixing identification  
with modeling.

> Bruce D'Arcus wrote:
>> So based on conversation today, here's what I'd suggest:
>>
>> 1) use xml:id to identify document elements
> We have here already a decision to be made. Do we use xml:id or do  
> we use meta:id and require an IRI for RDF way of binding?

Yes, this is the decision.

> I earlier preferred the IRI binding, but I do not like to have two  
> different types of IDs in the content. xml:id and meta:id, which as  
> additional to xml:id the restriction to be an IRI.
> If we use a xml:id, we have to solve the problem of relative links,  
> once the validation of an RDF/XML with relative provided a  
> deprecation warning using
>
> http://www.w3.org/RDF/Validator/
>
> Now the relative link is (incorrectly) resolved by exchanging '../'  
> with 'http://www.w3.org/RDF/Validator/' (already reported).
>
> Elias once came up with the idea of using a xml:base URL, which  
> might be theoretically different for every RDF/XML file of the  
> package.

Yes, and I think we should do this.

> Furthermore to make things for RDF comparable we suggested to use  
> owl:sameAs
> http://www.w3.org/TR/owl-ref/#sameAs-def
>
> Any further details I have not mentioned that might help us to find  
> a decision?

Yes, having a base document URI and then local xml:ids makes it  
easier to annotate documents externally (Rob's use case). Also,  
hainvg the base URIs makes it easy to relate documents.

We could just say something like:

A document shall have an IRI that uniquely and persistently  
identifies the document and can serve as the base IRI for local  
xml:id resolution. Where specific HTTP or other IRI schemes are not  
used, URN encoded UUIDs should be used as a fallback.

Note: above is a strawman.

Bruce