- From: Johan De Smedt <johan.de-smedt@tenforce.com>
- Date: Tue, 21 Apr 2009 23:33:16 +0200
- To: "'Antoine Isaac'" <aisaac@few.vu.nl>, "'Tudhope D S \(AT\)'" <dstudhope@glam.ac.uk>
- Cc: <public-esw-thes@w3.org>, <public-swd-wg@w3.org>, "'Lourens van der Meij'" <lourens@few.vu.nl>
Thanks for the many reactions. I have seen among many other things - the skos API approach - resource oriented rest interface (e.g. https://svn.eionet.europa.eu/projects/Zope/wiki/ReSTInterface) - SPARQL end-point This and reading about linked data inspired me to elaborate on the rest interface For Eurovoc we have a resource scheme providing URI without a # for concepts, labels and concept-schemes. Using the http Accept content option application/rdf+xml, the http server could send a graph for providing the relevant direct connections around a concept, a label, a micro thesaurus, ... This is different from the typical service interface but it accommodates easily for skos schema extensions An application would be able to use these extensions if it has knowledge about them. The approach does require to be complete in the sense that, inferences based on custom extensions to skos and resulting in skos class instances or skos property statements are done by the provider of the service, not by the client. Extending these URI with filtering capabilities (appending ? and query options) allows providing server dependent query functionality Example: - Retrieve a concept from using a full text search http://eurovoc.europa.eu/EUROVOC?searchType=fullText&language=en&matchingLit eral=... result: the RDF graph holding all concepts of the thesaurus that match the search criteria on any of its terms in the specified language: additional filters are possible - a micro-thesaurus base URI limits the search to concepts of the micro thesaurus - termClass=yyyy limits the search to the specified class of terms (PT, nPT) I think this approach combines rigor of a service interface and flexibility on custom rdf schema extensions. Thanks for reactions and advice. kr, Johan De Smedt. =================== -----Original Message----- From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] On Behalf Of Antoine Isaac Sent: Tuesday, 21 April, 2009 22:58 To: Tudhope D S (AT) Cc: public-esw-thes@w3.org; public-swd-wg@w3.org; Lourens van der Meij Subject: Re: SKOS API and web-service Hello, As you might have noticed that I've just announced a SKOS repository available via a web service [1], it won't come as a surprise that I support many of Doug's points below :-) Some of the motivations I can think of are in fact quite trivial: Guidance & expertise sharing: a service provides with well-identified functions, rather than let application designers wondering what to do in front of RDF data. In some cases this can be counter-productive, in some others it can help structuring practices and making application development faster. Designing a service may make one (or better, a community) think in terms of application/requirements, which can be hugely valueable. This feature becomes also especially useful when it comes to sharing functions that require specific expertise. This is I guess the case of the query expansion mechanisms Doug and Ceri propose, which capitalize on a lot of existing work. (and of course, technically, query expansion patterns in some cases can be really tedious to reproduce in SPARQL, and sometimes even out of reach). Control & performance: from a data provider perspective, it may not be wise to release a SPARQL endpoint--building a service around an RDF source is also a good means to disallow unoptimized SPARQL queries, or queries that even optimized would put a repository on its knees. The ones getting the complete descriptions of a vocabulary's concept, for instance. We had an additional motivation, which might be seen as related to both previous aspects: in principle, our service can allow access to data which is distributed over different services, and manage this based on concept scheme-related information. A kind of mixture between scalability-oriented data management and use of specific domain data, which might be difficult to reproduce with SPARQL and/or generic distributed RDF repositories. (but I prefer to stop here, as I'm really not an expert of that topic) Cheers, Antoine [1] http://lists.w3.org/Archives/Public/public-esw-thes/2009Apr/0022.html > Hi - following up on this and Al's subsequent email > > wrt other implementations, i know doug tudhope and ceri binding have > an implementation of the skos web service api with some extensions, > but i don't know what the release status is. > Ceri Binding developed a set of web services, based upon SKOS Core data > model (v1) for the purposes of the STAR project [3]. The services > currently provide term look up across the thesauri held in the system, > along with browsing and semantic concept expansion within a chosen > thesaurus. > > The service is based on a subset of the SWAD Europe SKOS API with > extensions for concept expansion. Details and the API at > http://hypermedia.research.glam.ac.uk/kos/terminology_services/ > (may need to copy/paste the url to avoid our email server) > and background references at [1,2], including a review of previous work > on KOS APIs and use patterns. Anyone interested is welcome to inspect > the API or download a client demonstrator of basic functionality. > > SKOS_WS is a SOAP web service written in C#, running on Microsoft .NET > framework. The current implementation is SOAP based but we believe that > a REST based http version would not a big step. We haven't made the > service code available to date as it is still under development for STAR > and a new Tag Recommnder project just starting. However, we are > committed to publishing the server software as open source by the end of > the STAR project and anyone interested in collaborative API development > is welcome to contact me regarding an interim snapshot version. The > current version uses the SemWeb RDF library. > > Within the project, we've also been discussing the relative pros/cons of > a specialist SKOS web service vs a general RDF query language (SPARQL) > and would be interested in any wider discussion. > > Different conditions may favour the one or the other. A SPARQL endpoint > lets you do anything supported by SPARQL and does not restrict to the > specific services exposed. However it may be found that some > functionality is not easy/possible in SPARQL. A service API could be > implemented on top of SPARQL or via another platform and does not have > to be a web service, although web services offer a platform neutral > capability (potentially available as an external, third party service). > > Al (Dan) mentioned issues as to whether any API functionality might be > hard to realise efficiently in SPARQL, eg text-based query or iterative > cost-based concept expansion. Other reasons for a specialised API (or > program library) could be if some developers, making use of SKOS, prefer > not to be constrained to SPARQL for any reason (eg security issues in > exposing the database, skillset issues or existing platform > constraints), or if the API functions correspond to common use cases > that can be provided at a higher level. > > Doug > > 1. Background on KOS services and user interface patterns - > Binding C., Tudhope D. 2004. KOS at your Service: Programmatic Access to > knowledge Organisation Systems. Journal of Digital Information, 4(4) > http://journals.tdl.org/jodi/article/view/110/109 > > 2. Concept based query expansion paper > Tudhope D., Binding C., Blocks D., Cunliffe D. 2006. Query expansion via > conceptual distance in thesaurus indexed collections. Journal of > Documentation, 62 (4), 509-533. Emerald. > http://hypermedia.research.glam.ac.uk/media/files/documents/2008-04-02/J > DOCfinal-Tudhope.doc > > 3. STAR - Semantic Technologies for Archaeological Resources > http://hypermedia.research.glam.ac.uk/kos/STAR/ > > > Douglas Tudhope > Professor, Faculty of Advanced Technology > University of Glamorgan > Pontypridd CF37 1DL > Wales, UK > Tel +44 (0) 1443-483609 > Fax +44 (0) 1443-482715 > Editor : The New Review of Hypermedia and Multimedia > > > -----Original Message----- > From: public-esw-thes-request@w3.org > [mailto:public-esw-thes-request@w3.org] On Behalf Of Alistair Miles > Sent: 14 April 2009 12:47 > To: Johan De Smedt > Cc: public-esw-thes@w3.org; public-swd-wg@w3.org > Subject: Re: SKOS API and web-service > > hi johan > > On Wed, Apr 08, 2009 at 08:42:32AM +0200, Johan De Smedt wrote: >> Dear, >> >> Following the new CR for SKOS, >> is there an update planned for >> http://www.w3.org/2001/sw/Europe/reports/thes/skosapi.html ? > > no, this wasn't in scope for the swdwg. if folks would like to use > this list to discuss a community-led update to the skos web service > api that would be great. > > i know doug tudhope and ceri binding at glamorgan have worked on this > fairly recently, they use concept expansion methods to support > information retrieval. > > adding to what dan said, the skos ws api was written before there was > sparql. it would be nice to look again at the skos ws api, in light of > sparql, and to ask which methods really add something over sparql, > either in terms of convenience or functionality. e.g. you can't do > cost-based expansions with sparql, at least not easily. you also can't > do very efficient text-based queries. some stuff you can do tho, > e.g. see [1]. > > cheers, > > alistair > > [1] > http://lists.w3.org/Archives/Public/public-esw-thes/2009Mar/0017.html > >> Thanks for information or advice. >> >> Kind Regards, >> Johan De Smedt >> ================= >> johan.de-smedt@tenforce.com >> mobile: +32 477 475 934 >> ================= >> >> >
Received on Tuesday, 21 April 2009 21:34:00 UTC