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

In thinking about this I too have been leaning towards not using the  
hash form. In my case I was initially ignorant of the fact that stuff  
after the hash isn't sent to the server, and I think the server,  
which both knows much more about the domain, and often has more  
computational power available to it ought to have some more control  
over what is returned for such a query.

Moreover, it is hard to figure out, at the outset, whether an  
ontology will be "big" or "small", or what the "natural" chunk size  
would be.

Another issue is what sort of work the client needs to do in order to  
extract the part referred by the fragment identifier from the whole  
ontology. Is this obvious?

Regarding the issue of round trip, i think that with OWL there is a  
clear way to provide both.
When returning just the definition of a specific class or property,  
in order for it to make sense in OWL, it needs to specify an  
owl:imports of the full ontology. I would suggest that the full  
ontology be served at that URI. Clients who retrieve a single  
definition can then decide whether they want to dereference items one  
at a time, or to retrieve the whole ontology  by dereferencing the  
import.

On the server side, of course, there need not really be a document  
for each definition  - the server can handle packaging up a single  
definition from the larger file.

My 2c,

Regards,
Alan

On Aug 4, 2006, at 10:32 AM, Dan Connolly wrote:

>
> 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 :
>>> 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.
>
> 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.
>
> 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).
>

Received on Friday, 4 August 2006 20:41:16 UTC