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

> Isnt that as ambiguous as any human readable description, includign
> the comments which describe the terms of ontologies?

Possibly. The difference is that the tdb URIs are used to describe a  
resource by its relation to another (mostly non-RDF) URL, which is  
arguably less precise; the only distinctive part of the URI is the  
HTML document it refers to, and there are many-to-many relationships  
between the referents and the signs, to borrow semiotics terminology.

> I am a fan of tag uri!
> we support them in DBin (the first thing you get when starting up is a
> proposed tag uri for you as a user). But they are to be used if you
> want to make sure there is no possibility of collision. Talking about
> pets, beers YOU brew etc. For any other (and most?) identification
> purposes  you really want to "collide" with others..

It's a tradeoff, of course, between allowing 'good' accidental  
collision and avoiding 'bad' inadvertent collision. Completely unique  
URIs will never cause erroneous collisions, but they don't allow  
useful accidents. I suspect that the right thing to do is not to rely  
on colliding URIs at all, but instead to use IFPs, CIFPs, or rules to  
infer identity. IMO the useful collisions are mostly limited to  
'native' web resources (mailto: URIs, web resources themselves, SIP  
endpoints) and not the real-world things to which ontologies refer.

> If you only mint your own then put a bunch of "sameAs" would be the
> same.. are we not allows to talk about URIs we dont own? Talking about
> and minting sound the same to me ..

The difference between these (using the same URIs versus using  
different URIs and relating them) is the ability to control the  
inference of identity. I could only infer identity based on trust  
relationships, say, or operate in a strict mode where I don't merge  
data at all.

When I refer to someone else's URI, and it's owned by them, I am  
implicitly agreeing that I'm referring to the same thing that they  
are referring to, and they can choose what that is because they own  
the domain. (The point of the ontology comments is to try to  
unambiguously convey the referent to me.)

When two people mint a tdb URI, and they collide, there is a risk  
that they are each referring to a different concept with the same  
identifier. There is no way of deciding who is wrong, or even  
detecting the problem.

>> Not necessarily, but it's recommended that dereferencing a URI
>> returns an 'authoritative' description of that resource.
>
> when the URL is hostd by someone who "owns the idea" .. +1 tdb

The problem is that the authoritative description is not RDF, so one  
can't be sure precisely what it's a description of. It allows for  
useful collision at the human level (we probably have some idea of  
what http://slashdot.org/ is referring to), but I daresay it's not  
enough for machines. ("Slashdot contains 2 million comments, is  
composed of 200,000 users, started in 1994, started in 1999, has a  
profit margin of $30k, and 6 million rows stored in an Oracle  
database? That's confusing!")

>> > 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.
>
> From my understandign the "uri opacity" in the SW is somehow an
> extension to a principle which is sound sound limited to HTTP only..

...

> Example.. if its a ISBN uri it could show you a page from your
> favorite bookstore with prieces and comments about that book. If its a
> URL.. well.. just invoke the system browser, if it is a tag URI, since
> the specs say "put your email" then it could show a button which says
> "email the minter and ask what he meant :-) "

:)

For something like an ISBN in a book application, then sure --  
introspect away. I think that's specialized and rigorous enough. In a  
more general sense, though, there are several reasons to keep  
discrete pieces of data separate within the model, rather than within  
the URI. For instance, in this case I'd have to put conditionals  
throughout my URI handling code to spot these URIs and act on, or  
ignore, the date; I might have to do that for tdbs, tags, various URN  
info schemes... I generally feel that if another approach exists it's  
better to take it.

-R

Received on Friday, 22 September 2006 23:55:33 UTC