- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Tue, 17 Oct 2006 18:44:58 +0200
- To: Bernard vatant <bernard.vatant@mondeca.com>
- Cc: Semantic Web <semantic-web@w3.org>, Marc <marc@geonames.org>
Bernard, On 17 Oct 2006, at 16:41, Bernard vatant wrote: > Some "machines" can very well know the web service they call and > what to do with the results. There are not only random crawlers and > browsers. There are also integrated applications calling an > external data base / service, but knowing preety well how to call > it and what to do with the results. That is what is called Service > Oriented Architecture, no? Isn't that just a Web API like the ones geonames.org already provides? The difference to the SemWeb: You need a specific Google API client or Amazon API client or Geonames API client to access the Web APIs, while a generic SemWeb client can interface with and discover all linked data. >>> Maybe some user would like that kind of description to feed a >>> data base, others would like only the direct children of type >>> A.ADM1 etc. >> >> Note that SPARQL provides a better and standardized solution to >> that kind of problem. AFAIK you already provide a database dump of >> the Geonames data; third parties could use this to set up a SPARQL >> server (e.g. using D2R Server [3]). Or, if your data is linked up >> properly, use a dynamic-dataset SPARQL engine (e.g. using the >> SemWebClient library [4]). > Sure enough. but in fact all the point of the exercice (from my > viewpoint) was to figure to which extent a "classical" data base > (that is, not built on RDF) like geonames, with already a bunch of > web services, was able to also provide RDF data without installing > a proper RDF server. If afterwards someone (may geonames > themselves) want to set up all you say, all the best. But the > original objective was smooth, effortless, costless migration. Sure, and that's exactly the point I was trying to make: Just get the data out there, in a way that it is discoverable by automated tools. Don't make things complicated by adding all these parameters; if there's a need for more flexibility down the road, then there are already ways how you *or* someone else can add it easily later on. Richard > > Bernard >> >> Keep it up, >> Richard >> >> [1] http://dowhatimean.net/2006/10/fixing-ambiguous-concept-uris >> [2] http://www.w3.org/DesignIssues/LinkedData.html >> [3] http://sites.wiwiss.fu-berlin.de/suhl/bizer/d2r-server/ >> [4] http://sites.wiwiss.fu-berlin.de/suhl/bizer/ng4j/semwebclient/ >> >> >> >>> Note that such hypothetical URIs actually work right now, but the >>> added parameters are not really processed and they are equivalent >>> to (2). >>> >>> And I guess, like in other geonames Web services, (2) would yield >>> a description with default values for parameters used in (3) and >>> (4) and the like. In that case, the description of (1) yielded by >>> (2) through 303 redirects will be neither "complete", nor >>> "canonical", nor "authoritative" ... but just a "default" >>> description. >>> >>> Is this correct TAG-wise? This time I ask before ... :-) >>> >>> >>> Bernard vatant a écrit : >>>> >>>> Hello all >>>> >>>> I'm very pleased to announce that, through a quick and efficient >>>> collaboration with Marc (in cc), the 6 million and growing >>>> geographical features in the data base of Geonames [1] are now >>>> described by a OWL ontology [2], and the RDF description of each >>>> instance, including names, type, of course geolocation elements, >>>> is now available through Geonames Webservice, adding to an >>>> already impressive pack of services [3]. >>>> The ontology is very simple, and leverage elements of the >>>> wgs84_pos vocabulary [4]. The feature types are described using >>>> a simple SKOS vocabulary, which has been embedded in the OWL >>>> ontology. >>>> >>>> If you add that, thanks to Google Maps API, the geonames >>>> features can be created and edited through a wiki-like interface >>>> [5], this as Web 2.0 as can be. >>>> >>>> Comments welcome, either here or in the Geonames forum [6] >>>> >>>> Bernard >>>> >>>> >>>> [1] http://www.geonames.org >>>> [2] http://www.geonames.org/ontology/ >>>> [3] http://www.geonames.org/export/ >>>> [4] http://www.w3.org/2003/01/geo/#vocabulary >>>> [5] http://www.geonames.org/recent-changes/ >>>> [6] http://forum.geonames.org/gforum/posts/list/156.page >>>> >>> >>> -- >>> *Bernard Vatant >>> *Knowledge Engineering >>> ---------------------------------------------------- >>> *Mondeca ** >>> *3, cité Nollez 75018 Paris France >>> Web: www.mondeca.com <http://www.mondeca.com> >>> ---------------------------------------------------- >>> Tel. +33 (0) 871 488 459 Mail: bernard.vatant@mondeca.com >>> <mailto:bernard.vatant@mondeca.com> >>> Wikipedia:universimmedia <http://en.wikipedia.org/wiki/ >>> User:Universimmedia> >>> >>> >>> >> >> >> >> --No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.408 / Virus Database: 268.13.4/477 - Release Date: >> 16/10/2006 >> >> > > -- > > *Bernard Vatant > *Knowledge Engineering > ---------------------------------------------------- > *Mondeca ** > *3, cité Nollez 75018 Paris France > Web: www.mondeca.com <http://www.mondeca.com> > ---------------------------------------------------- > Tel. +33 (0) 871 488 459 Mail: bernard.vatant@mondeca.com > <mailto:bernard.vatant@mondeca.com> > Wikipedia:universimmedia <http://en.wikipedia.org/wiki/ > User:Universimmedia> > >
Received on Tuesday, 17 October 2006 16:45:13 UTC