W3C home > Mailing lists > Public > semantic-web@w3.org > September 2006

Re: A URI for your Favourite Pub: httpRange-14 Question

From: Richard Newman <r.newman@reading.ac.uk>
Date: Fri, 22 Sep 2006 19:44:54 +0100
Message-Id: <65B7243A-A36A-4389-A3AE-616464022E7A@reading.ac.uk>
Cc: "T.Heath" <T.Heath@open.ac.uk>, semantic-web@w3.org
To: Giovanni Tummarello <g.tummarello@gmail.com>

Hi Giovanni,
   A few random thoughts:

> Second, since its not an http but its something different, it can  
> be given a clear semantics. Semantics of http is
> get the document at. Semantics of tbd: is "we're referring with a  
> URI to the things that in that date was available at"
> so .. since its given in the semantics that second part is a URI  
> then one is free to dereference the second part and fall back
> into the usual scenario.. but with no ambiguity.

... except that it is ambiguous. If I say

<http://mydomain.com/slashdot>

I control what I mean. Your reuse of my identifier is an implicit  
contract (at least, that's how ontologies work -- this agreement  
gives them their mapping into the real world). However, if both you  
and I visit Slashdot at the same moment, we end up with the same tdb  
URN. I'm referring to the community, you're referring to the business  
entity, but we can't tell them apart. It's hardly better than using  
the URL, and provides nothing over a 'subject' IFP (as Danny already  
mentioned).

Compare and contrast with the tag URI.

<http://www.taguri.org/>

"The tag algorithm lets people mint  create  identifiers that no  
one else using the same algorithm could ever mint."

Either use a tag URI or a bnode, and point to the describing page  
with an IFP. The semantics are clearer.

> Third, its extremely likely that others will automatically reuse  
> that URI.
> One can argue if this is fundamental component of the SW or not. I  
> think it might be, but nobody can deny the
> immense usefullness of this feature.

That might well be a bad thing, depending on what they mean by using  
that URI...

> Forth, you're not minting into any other's namespace. Not that i am  
> sure that is necessarely a bad
> thing becouse nobody can enforce this on the SW since there is by  
> definition nothing to get from the
> owner of the domain (there is no get call). Plus.. anyone can talk  
> aobut any URI .. who cares then if that doesnt exist?

Well, you're minting into a shared URI space :)

> If i see that someone said something about a URL (http://g1o.net  
> isA uglypage) should i really go check if that someone was the  
> owner of the URL before reusing the URL in a statement myself?

Not necessarily, but it's recommended that dereferencing a URI  
returns an 'authoritative' description of that resource.

> SW is about reuse.. so since that is not possible .. i guess there  
> is nothing wrong.
>
> Fifth, the date part then adds the level of stability, yet cripples  
> a bit the previous definition (people could refer to the same thing  
> looking at the respective web page at different times..) . Having  
> the semantic of it however allows one the
> decide whether to ignore the date and smush on that.. or do  
> whatever else, also according to the "type".

URIs are meant to be opaque. Better would be to use named graphs to  
provide a context so that the date, user etc. become explicit.

> ... just the final note. In DBin pub application we provide the web  
> site
> of a pub listing engine to the users who want to talk aobut their
> favorite pubs, they can locate their pub there, and dbin sticks a good
> old # in the end :-) RDF things the URL and the #URI are different.
> Browser see them as equals.

That's a really neat trick! I do forsee problems with <http:// 
example.com/pubslist.html#myFavePub>, but if you control the source  
page 'sall good.

> my 2 pragmatic cents, but will be happy to understand further or  
> change
> my mind if it is the case:-)

That's a refreshing attitude to see on a mailing list :D

-R
Received on Friday, 22 September 2006 18:45:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:53 UTC