Re: INSEE releases OWL ontology and RDF data for geographical entities

Eric van der Vlist wrote:
> Le dimanche 06 août 2006 à 10:59 -0400, Joshua Tauberer a écrit :
>> Eric van der Vlist wrote:
>>> Le dimanche 06 août 2006 à 15:45 +0200, Hans Teijgeler a écrit :
>>> 
>>>> Please elaborate on what you exactly mean with that roundtrip.
>>> If I understand the spec correctly, if you load a XML/RDF
>>> document with weird namespaces names such as http://foo.com/b or
>>> http://foo.com#b in a RDF parser and serialise the model back
>>> into XML/RDF, in addition to the common "roundtrip" issues, the
>>> result could use different namespace and local names than the
>>> original document!
>> What difference would that make (besides it possibly not looking as
>>  pretty)?  The input and output documents will still be entirely
>> equivalent.
> 
> Please read my mail in the context of the question to which it is 
> answering!

You're right.  I lost track of the thread somewhere.  Going back
further, I see I missed (i.e. failed to read carefully) Dan's email
mentioning the web architecture rec (http://www.w3.org/TR/webarch/).

So that's to be understood as covering URIs mentioned in RDF?  (I ask to
the list at large, maybe rhetorically.)  Any dereferencable URI found in
any RDF document is expected to (i.e. "SHOULD") dereference to a
representation of the entity denoted by the URI.  Ok.  There it is.

Can I infer anything from the dereferenced representation if it's not a
RDF document?  That is, if I find a URI <http://www.w3.org> in an RDF
document and I dereference it and find a text/html document, am I
permitted to infer that the entity named by <http://www.w3.org> was
intended to denote the web page at that address?  Is this a question
that the webarch document answers?

-- 
- Joshua Tauberer

http://razor.occams.info

"Unfortunately, we're having this discussion. It's too bad,
because guess who listens to the discussion: the enemy."

> 
> In that specific case (see my answer to Hans), I don't think we can
> say that <ar xmlns="http://foo.com/b"/> and <bar 
> xmlns="http://foo.com/"/> are really equivalent even if they generate
>  the same triples.
> 
>> Just to throw in my two cents into this thread, while I'm emailing 
>> (although I don't expect to say anything no one has said before) --
>> 
>> 
>> It seems like issues about # versus /, choosing good namespace
>> URIs, and dereferencing are all very fragile issues.  As we are
>> right now, we've been told (by the specs, implicitly if not
>> explicitly) that there's nothing in a name.  They're supposed to be
>> opaque.  So if I start coining millions of http:-schemed names, I
>> have an expectation that tools *are not* going to bombard my server
>> with millions of HTTP GETs trying to find things because you're not
>> *supposed* to look inside a URI.
>> 
>> If that's not what we want, that is, if there is any (formal) level
>> of expectation that http-URIs are intended both 1) to denote an
>> entity and 2) to be potentially dereferencable to something, then
>> the W3C better say so very soon so I know that if I don't want
>> millions of HTTP GETs, I better not use http:.
>> 
>> In the meanwhile, until some standard says that http: URIs are
>> expected to be even potentially dereferencable, my feeling is that
>> we should just drop the idea that we can dereference anything
>> unless some triple explicitly says so.
> 
> Here, we're back to the starting point of our debate!
> 
> That's what we thought too and that's the principle we've followed
> with the current version of the INSEE OWL ontology.
> 
> Having been told that this was no longer a subject of discussion,
> that this was not how the Semantic Web worked and that we were
> violating the rules of the Web Architecture, I am now trying to find
> a solution where we do not rigidly tight the identifiers of abstract
> resources to the addresses of web resources and can still let people
> dereference our URIs if they really want to :) ...
> 
> Eric
> 
>> (OTOH, I have been using tag: anyway because I find http:
>> unnecessarily confusing.)
>>

Received on Sunday, 6 August 2006 20:42:20 UTC