- From: Dan Connolly <connolly@w3.org>
- Date: Fri, 04 Aug 2006 17:39:01 -0500
- To: Bernard Vatant <bernard.vatant@mondeca.com>
- Cc: semantic-web@w3.org, Eric van der Vlist <vdv@dyomedea.com>, Franck Cotton <franck.cotton@insee.fr>
On Fri, 2006-08-04 at 23:53 +0200, Bernard Vatant wrote: [...] > And actually, this should be the general situation in SW publication : > there is no authoritative, definitive, complete, description of a > resource, packaged in one file, with a single access point. Yes, there are authoritative descriptions in the Semantic Web. Perhaps not complete definitions, but for a URI such as http://www.w3.org/2000/01/rdf-schema#subClassOf any document you get back by doing an http GET of http://www.w3.org/2000/01/rdf-schema is authoritative. That's how the web works: we all agree that if you lease/buy a domain name, you get to say what the URIs starting with http:// and that domain mean, and we agree that if you run a web server and serve up documents there, they are authoritative w.r.t. the meanings of those URIs. Anybody else is free to say things about rdfs:subClassOf, but the document that W3C serves up at http://www.w3.org/2000/01/rdf-schema says that rdfs:subClassOf is an rdf:Property, and is some other document says that it's not an rdf:Property, that other document should be considered in error. > So, the best an URI can do, when its referent is not an accessible > thing, and that its main purpose is identifying the resource in > distributed descriptions, if one wants to make sense of it through > http protocol - since it's an http URI after all - is to get acces > some information like : "Sorry, what you try to access by this URI is > not an accessible resource. But its description can be found in RDF > files X, Y, Z, ...". That's not the best we can do. If you use URIs of the form DOC#TERM for non-information resources, then the information resource DOC can say things like { <#TERM> rdf:type geo:City }. > And the more I think about it, the more I think that the 404 page > that you get through http://rdf.insee.fr/geo/COM_80078 is close to > that. Agreed, the current message displayed on the page is suboptimal, > independently of the fact that it is in French, but replace it by the > quote I suggest above, and it makes much more sense that any fragment > identifier. Really? It doesn't appeal to me at all. > Maybe in contradiction with what I wrote in a previous message, where > I suggested that maybe we could have kept the # namespace for the > ontology, I think now that this argument holds for ontology elements > as well. Granted, we have now published a single ontology file > containing a description of e.g., http://rdf.insee.fr/geo/Commune. But > next year we can have another version, or another ontology defining > the same entity, with the same URI, at another level of detail, and > which the publisher would not like to see merged with the previous > one. Hmm... I can't imagine why not. Care to elaborate? > There again, packaging considerations naturally lead to define > several files containing partial descriptions of the same resource. It seems very unnatural to me to use anything other than a single static file for the case of an ontology with just a few dozen terms. Maybe a handful of content-negotiated static files. But not more than that. > I'm well aware this is highly controversial and certainly not in tune > with the TAG recommendation on httpRange14 issue. > > Bernard > > [1] > http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Friday, 4 August 2006 22:39:07 UTC