Other ideas, comments to local/global URI suggestion?

This stills needs some thinking:

The main problem is that I would like to give one object two ID's (one of 
them always unambiguous) either when it is created or at first give an 
unambiguous ID and then later a second ID.

Having to create two objects with an ID and then say they are the same 
seems to be a bit too much work when you only want to give a second ID. How 
are other people dealing with this?

And the starting point for this was the file:// URI not being unambiguous. 
But maybe that could be corrected too so that it solves our problems.

Marja

At 12:21 AM 4/9/2004 -0400, Marja-Riitta Koivunen wrote:

>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 Tuesday, 13 April 2004 08:44:51 UTC