Linking back to

Hugh, and all

Looking at the very cool stuff at, comes to my mind that at 
least, my old dream of "hubjects" has come true ...
Richard now points his finger at the moon, by asking "What is the 
semantics of a URI?"
Basically I would say "none" or "as closer to none as possible". And 
above all, the URI is *not* yet another URI for the thing 
identified by the URIs it connects.
It's the URI of a connector, the URI of a hub, the URI of a service. And 
great like that.

But now I would like, in the description of one of those URIs, reference 
this service. Example: provides 16 
equivalent URIs (including the original one).
At I've gathered painfully only 10 of 
those :-)
But now that is alive, why should I care maintaining those 
sameAs links locally? I would like to express in the local description 
at something like :
'There are more URIs identifying the same concept, you can find them at'
Using recursively owl:sameAs as Richard suggests seems to me plainly 
wrong. The french language is not a service.

Using rdfs:seeAlso is as usual good but not precise enough. Maybe could provide a minimal vocabulary to describe its URI, such 
as some property     sameas:hub

Maybe it's not the best way to do it, but you see the idea ...


> On 04/06/2009 09:20, "Dan Brickley" <> wrote:
>> On 4/6/09 01:54, Richard Cyganiak wrote:
>>> Hugh, Ian,
>>> Great work -- simple, visually attractive, does what it says on the tin.
>>> A pleasure to use.
>> Yup! :)
>>> I think it would be pretty cool to make it
>>> <#this> owl:sameAs <U1>, <U2>, <U3>, <U4> .
>>> That way, I could add a nice triple to my FOAF file:
>>> <#cygri> owl:sameAs
>>> <>
>>> .
>>> (Okay, I like this mostly because of the recursive cleverness of the
>>> idea. In reality, an rdfs:seeAlso would probably do just fine. But isn't
>>> owl:sameAs sooo much sexier?)
>> The risk here is that moves in role from becoming a provider
>> of annotations on other people's identifiers, to becoming a provider of
>> re-usable identifiers. If they want to go this way, that would be great,
>> but I'd hope to see some explicit commitment from the Southampton team
>> that they were confident the service (at least in frozen form) could be
>> maintained for some years. Sometimes even with the best will in the
>> world, economic, organizational and other facts mean that services can't
>> be maintained. and similar services could be really handy
>> (like for use with RDF but it would be good to know how much
>> we can rely on URIs in the namespace remaining usable, before
>> putting too much weight on them.
>> Hugh - this is probably early days to ask such dull questions, but have
>> you thought about this?
> Yes.
>> Might it be possible to have the site offer
>> URIs, and some commitment they'll probably be around for a few years (or
>> somehow opensourced to collaborative maintainance if Southampton decide
>> not to maintain it later?).
> No :-)
> Thank you for answering this bit of Michael's post so well.
> Our strong view is that the solution to the problem of having all these URIs
> is not to generate another one. And I would say that with services of this
> type around, there is no reason. Use an existing one, or construct a new one
> and make sure it is known about.
> If you want permanent new URIs, try using okkam, and we will hope to have
> more of okkam in our system soon.
>> The reason I go on about this topic first is I could see people very
>> easily relying on such services, and doing so for many millions of
>> identifiers.
>> Another thought: take a look at Social Graph API from Google; this might
>> help with people identification -
>> eg. for me,
> 5
>> gives:
>> 1.
>> 2.
>> 3.
>> 4.
>> 5.
>> 6.
>> 7.
>> 8.
>> 9.
>> vs Google's
>> %23danbri&fme=1&pretty=1&callback=
> Thanks.
> I guess the first question is, should I trust it?
> By the way, it seems that you are badly co-reffed in out system - sorry :-)
> (And I am not going to "fix" it, so we can see how the background systems
> run.)
> By the way, if you want the social/network graph, you can put the URI into
> Eg
> d/person-62ca72227cd42255eb0d8c37383eccf0-2e1762effd1839702bc077c652d57901
>> Another thought - is the whole system necessarily based on pre-loaded
>> data, or could make some explorations of the Web "while you
>> wait"? eg. do a few searches via Yahoo BOSS or Google JSON API and parse
>> the results for same-as's.
> I would avoid this.
> For it to be a service of the kind that John would use, I think it needs to
> provide a guaranteed fast response (at least in the sense of no other
> unexpected dependencies).
>> Re "bad results" it's worth looking at what Google SGAPI does. They
>> distinguish between one sided claims vs reciprocations. If my homepage
>> has rel=me pointing to my youtube profile, that's one piece of evidence
>> they have a common owner; if the profile has similar markup pointing
>> back, that's even more reassuring....
> Ah yes, now that is a big topic. Several PhDs on trust and provenance to be
> done here. What is the provenance of each of the pairwise assertions, how
> does that contribute to the bundle, how do multiple assertions from
> different sources contribute? In fact, what is the calculus of all this?
> Cheers
> Hugh
>> cheers,
>> Dan
>> cheers,
>> Dan


*Bernard Vatant
*Senior Consultant
Vocabulary & Data Engineering
Tel:       +33 (0) 971 488 459
Mail: <>
*3, citÚ Nollez 75018 Paris France
Web: <>
Blog:    Lešons de Choses <>

Received on Monday, 8 June 2009 11:23:32 UTC