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 20:58:23 UTC