RE: SKOS API and web-service

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