Re: reasonings for current local/global URI suggestion

At 07:26 PM 4/15/2004 +0200, Jose Kahan wrote:

>Marja,
>
>I finally understood what you were trying to say so I can give you
>now my feedback.
>
>On Fri, Apr 09, 2004 at 12:21:53AM -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.
>
>[cutting all the preliminary work and just leaving the final suggestion]
> >
> > <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>
>
>This one won't work well if you change the location of the bookmark
>file  because we can't assume how an RDF parser will parse/serialize.
>In Redland's case, it will make complete URIs out of fragments.
>If you make a bookmark that belongs to a topic, it will have
>a value similar to
>
>  <b:hasTopic r:resource=" nnn://current_location/filename#bbbbtopic1" />
>
>where nnn could be file or http or some other kind of URL type.
>
>Then, if you changed the location of the file, the current location
>would change and you wouldn't be talking about the same resource because
>any new bookmarks would be using nn:new_location/filename#bbbbtopic1
>instead of #bbbtopic1 like you intended.

My understanding from our discussion was that it will work when publishing 
the file but not if we store the topic and bookmarks in the file to a server.

The idea is that the URN defined by owl:sameAs is always used from outside 
file references when the file is local and does not have an unambiguous 
HTTP URI. The owl:sameAs URI is as good a URI as the rdf:ID.

When we publish the file with a topic and a reference to it only then 
bookmarks outside the file start using the http URI of the topic. When the 
bookmarks and the topic are in the same file the URI base should be the 
same inside the file no matter where it is moved. But naturally inside 
hasTopic references could as well use the URN too. And outside we said we 
used the URN until the file had a HTTP URI.

On the other hand if we moved the published file again the URIs would 
change again and even if the store the history of all locations with 
owl:sameAs like you suggested we might not want that to happen so I'm fine 
with having full HTTP URIs like you descriped in 
http://www.w3.org/Talks/040301Annotea/slide4-0.html. In that case we can 
use the first HTTP URI s as long as we want, unless we are afraid someone 
starts reusing them.

If we store the bookmarks and the topic to a server they would be parsed 
and given new unambiguous HTTP URIs too. The only time I see problems by 
using fragments is if every object in the file is parsed separately and not 
together.


>In order to know that you were using the same resource, you'd need
>to be able to use the owl:sameAs and put more intelligence into
>the applications. So finally, the work you wanted to save would
>make things more complex.
>
>Also, the r:id resolution would be local to a file so if you used
>another application to describe something about this resource, you'd
>have the local name, rather than the URN.

I was leaning in using the URN in the local case especially when referring 
from outside the file.


>It may be interesting, though, to see if you can use
>
>Thus, I think that using "about:urn" rather than "r:id"
>is still the best solution.  Maybe there's a way to optimize this
>using r:id, but I haven't given it much thought yet.

I agree we go back to only giving a URN until the file is published and not 
worrying about changing the RDF.


>[snip]
>
> > -- 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.
>
>But wouldn't you need to refer to it in this case using a "#" if it's
>a fragment?

In the example it refers to the URN of the topic if it refers to the HTTP 
URI it would look like this
<b:hasTopic r:resource="#urn%3Auid%3Abbbbtopic1"/>
This is explained in Figure 17 http://www.w3.org/2003/12/20-local-global.html

Marja


>-jose

Received on Sunday, 18 April 2004 08:05:51 UTC