- From: <creed@opengeospatial.org>
- Date: Fri, 4 Aug 2006 11:04:58 -0400 (EDT)
- To: "Dan Connolly" <connolly@w3.org>
- Cc: "Eric van der Vlist" <vdv@dyomedea.com>, "Bernard Vatant" <bernard.vatant@mondeca.com>, semantic-web@w3.org, public-xg-geo@w3.org, "Franck Cotton" <franck.cotton@insee.fr>
I may be out in left field, but I was wondering (RDF aside), what is the relationship of this activity with other similar geo-tagging activities, such as http://geotags.com/geo/draft-daviel-html-geo-tag-00.html? Reason I ask is that from a standards persepctive, it would be nice to have one common approach (information model) for expressing a URL/URI and then have various serializations (XML or straight http or RDF etc) based on implementation requirements. Thanks for the clarification. Regards Carl OGC > > On Fri, 2006-08-04 at 09:28 +0200, Eric van der Vlist wrote: >> Hi, > > Hi Eric, > >> Le jeudi 03 août 2006 à 23:26 +0200, Bernard Vatant a écrit : >> > >> > Dan >> > > did you consider using # rather than /? i.e. >> > > http://rdf.insee.fr/geo#code_commune >> > > rather than >> > > http://rdf.insee.fr/geo/code_commune >> > > especially for ontologies, it's a lot easier to manage. >> > > >> > We did consider. Actually my first version of the ontology used a # >> > namespace. Eric (in cc) was the one who suggested a / namespace, >> > especially for the data and somehow convinced the rest of us. That was >> > six months ago, but if I remember correctly, the idea was that at some >> > point, each instance URI would be (should be, hopefully will be) >> > associated with, and access to, a separate resource, which is not >> > the case now. >> >> Yes, that was the first comment I did on your first proposal end of >> January. >> >> The idea was that to identify a city, http://rdf.insee.fr/geo/COM_80078 >> is better than http://rdf.insee.fr/geo#COM_80078. > > You might also consider http://rdf.insee.fr/geo/COM_80078#city for > the city itself and http://rdf.insee.fr/geo/COM_80078 for a document > about the city. > > If the cities come in natural chunks, perhaps > http://rdf.insee.fr/geo/COM_800#city78 > for the city and http://rdf.insee.fr/geo/COM_800 for a document about > the cities in some region. > >> Of course, these URIs >> are only identifiers but who konws, we might want some day to publish >> some kind of documentation (like we do in RDDL to document namespaces) >> at these URIs. > > "only identifiers"? sigh. I got the impression you wanted to publish > information about them in the Semantic Web. > >> If we do so, the first URI makes each city a standalone entity while the >> second one means that they need to be fragments in a huge document which >> can cause a lot of issues (we don't know which media types we might want >> to publish and the definition of fragments is inconsistent between media >> types > > It's within your control to choose media types where the definition > of fragments is consistent. The easiest way is to just use one > media type: application/rdf+xml . > > >> (some of them don't even support fragments), the document might >> grow very large, ...). >> >> Now, the thing that we've not considered is to have a namespace URI >> different from the RDF base. >> >> > Agreed, we could have kept the # namespace for the ontology at least. >> >> Dan, can you elaborate why that makes ontologies a lot easier to manage? > > Because with a # namespace, publishing the ontology just involves > sticking one static file on a web server. (the URI looks nicer > if the web server can handle leaving the .rdf or .owl off, but > that's not completely essential). > > And then to look up http://rdf.insee.fr/geo#code_commune , a consumer > just GETs http://rdf.insee.fr/geo as usual; then when they want > to look up another term such as http://rdf.insee.fr/geo#subdivision, > they can save a round trip because they already have it. > > Using a / namespace has a higher cost for the producer (redirects) > and for the consumer (one GET per term rather than one GET > for the ontology). > > >> Thanks; >> >> Eric >> >> > > -- > 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 15:12:16 UTC