reasonings for current local/global URI suggestion

Jose asked me to explain the last changes I did to the local/global URI 
document (http://www.w3.org/2003/12/20-local-global.html) selected 
solution. Here is the reasoning.

-- Starting point:
I first gave a URN to a local (unpublished) bookmark by using

<r:Description r:about="urn:uid:xxxxbm1">
   <recalls r:resource="http://sample.example.com/appledoc"/>
   <b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
</r:Description>

Then I want to publish the bookmark and give it also an HTTP URI in 
addition to the URN. But I'm not sure what is the best way to give an 
object several IDs. My understanding is you can only have one r:id or r:about.

-- First try:
I tried first to publish the bookmark with an additional URI that is now 
going to be used instead of the URN but keep the URN as a reference if 
needed. I tried to do it without changing the whole definition but merely 
adding some new info:

<r:Description r:about="urn:uid:xxxxbm1">
   <recalls r:resource="http://sample.example.com/appledoc"/>
   <b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
   <owl:sameAs r:resource="bm1"/>
</r:Description>

But if I understand it right the <owl:sameAs r:resource="bm1"/>  is not 
really giving the bookmark and HTTP URI just referring to an already 
existing URI. So I'm not sure how we expect a browser to react if I try to 
give it http://...#bm1 after the above definition?

-- Current suggestion
I thought that maybe it is better to give a fragment URI with r:id already 
at the beginning but just not use it while it is local (not published). 
This saves as from changing that part of the file when it is published. We 
still may want to change the URN topic references when we can as is done here.

<r:Description r:id="bm1">
   <recalls r:resource="http://sample.example.com/appledoc"/>
   <b:hasTopic r:resource="#bbbbtopic1"/>
   <owl:sameAs r:resource="urn:uid:xxxxbm1"/>
</r:Description>

So this simply defines the fragment URI earlier in addition to the URN to 
help prevent changes and define an HTTP ID. For some reason referring to a 
URN with owl:sameAs does not bother me as much as to a fragment ID but 
maybe it should.

-- Possible next step
The last step was seeing if the URN and the URI could be somehow related. I 
thought it would be helpful. It may be that it only helps to create 
unambiguous fragment IDs automatically. If you know the HTTP URI you also 
know the URN, but you can get that info from the metadata definitions 
anyway. On the other hand knowing the URN does not help to totally solve 
the HTTP URI unless you also know the base (path) before the fragment.

<r:Description r:id="urn%3Auid%3Axxxxbm1">
   <recalls r:resource="http://sample.example.com/appledoc"/>
   <b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
   <owl:sameAs r:resource="urn:uid:xxxxbm1"/>
</r:Description>

The topic here may refer to a fragment ID if it is defined in the same file 
or to a published HTTP URI. Otherwise it needs to refer to a URN that can 
help to retrieve the rest of the information unless it has not been 
published or cannot be found.

Marja

Received on Friday, 9 April 2004 00:22:20 UTC