W3C home > Mailing lists > Public > public-annotea-dev@w3.org > April to June 2004

Re: reasonings for current local/global URI suggestion

From: Jose Kahan <jose.kahan@w3.org>
Date: Thu, 15 Apr 2004 19:26:53 +0200
To: Marja-Riitta Koivunen <marja@annotea.org>
Cc: public-annotea-dev@w3.org
Message-ID: <20040415172653.GG11372@inrialpes.fr>

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.

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.

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.

[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?

-jose
Received on Thursday, 15 April 2004 13:27:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:36:55 GMT