RE: SKOS API .... are u serious? Yes we are!

Hi Andy

> We wish the API was based on an existing standard such as SRW/SRU [1].
> It seems that you could create an SKOS SRW profile, like the Zthes SRW
> profile [2], instead  of developing yet another API.
>
>
Thanks for this comment - it is helpful to discuss these issues & we indeed 
did not discuss SRW in our documentation for the SKOS API although we had 
contemplated it prior to the development phase on DREFT.

I have worked (for my sins ;-)) with Z39.50 servers and clients over the 
years and so have had an eye on the development of SRW/U and knew about the 
Zthes profile etc. I can give you my view on the relationship of our work 
to SRW here, but first I think I need to clarify a misunderstanding:

*THE SKOS API IS NOT THE SAME THING AS AN SRW PROFILE*

'the API' that you refer to was an early attempt by ourselves to 
encapsulate and abstract away (at the layer shown below) the standard 
functionality that a SKOS thesaurus service will tend to offer at the API 
level. The API is based on an *evolving* standard - SKOS - that tries to do 
something that has not been done before - it aims to allow us to encode, in 
a machine-understandable format, the relationships between concepts in some 
KOS, and the relationships between those relationships :-).

Let's not confuse terms such as 'profile' in the SRW sense and 'API' [see 
http://www.webopedia.com/TERM/A/API.html].
An SRW profile is a set of constraints and usages on how a context set can 
be used, as I understand it. An API is more at the machine level - just the 
level that sits above the data store in DREFT's sense. The API we have 
defined can either be accessed directly (i.e. not even offered as a web 
service) by another software application (e.g. some client application that 
will present a nice end-user's browser view onto the thesaurus data), OR, 
be accessed via standard network protocols, for example as a web service.

DREFT:

(1)WEB SERVICE INTERFACE (publically exposed via WSDL, network protocol = 
http, usually)
|
(2)API  <- (X) direct access available for software apps
|
(3)DATA STORE

Where I think some of the confusion has arisen is around the fact that the 
WSDL we created for the prototype thesaurus web service (at layer (1) 
above) looks very similar to the API (which is at layer (2)); the 
operations are 100% related! This is due to the way the our work evolved in 
an incremental way.  However, there is no reason why the same functionality 
encapsulated in the API cannot be exposed as a variety of different 
flavours of web service, to suit community needs as they evolve. And SRW 
may be one of those needs.


THESAURUS WEB SERVICES & SRW:

OK, so I've already mentioned that the API is independent of whether 
machine access is via a web service interface or not. If it *is* to be 
accessed via a web service interface, we might want:

i) An explictly RDF-enabled data web service - i.e. essentially to enable 
apps to exchange RDF graphs of SKOS thesaurus data, via a doc/lit SOAP 
service OR RPC/SOAP encoded configuration. Here SRW is not a good fit - we 
don't want to constrain the data with some XML Schemas, but with the SKOS 
schema (or with the soap encoding schema, which has something of a good fit 
with the RDF data model, but that's another discussion ....). Here we might 
well want to enable query via SPARQL (upcoming RDF Query standard) and not 
CQL. This is an interesting area and one that we sadly did not get time to 
explore for the (SWADE) SKOS project.

ii) An SRW web service - this is where things are very XML-oriented and we 
would create an XML schema for the Concept, ConceptRelatives etc objects 
that we reflect via the SKOS API. We could create an SRW context set and a 
SKOS profile, sure.  CQL is a very useful query standard here, and we might 
want to extend the SKOS API in relation to it, to allow for searches on 
parts of fields and so on.

So what did we produce with DREFT? Neither i) nor ii) above. We chose a 
very generic option - an RPC/Encoded styled SOAP Web Service, built 
directly on top of the SKOS API. We've left the door open for further SKOS 
Thesaurus Web Service work ....!

Hope that is in some way clear,
thanks
Nikki


> Andy.
>
> [1] http://www.loc.gov/z3950/agency/zing/
> [2] http://zthes.z3950.org/srw/
>



----------------------
NJ Rogers, Technical Researcher
(Semantic Web Applications Developer)
Institute for Learning and Research Technology (ILRT)
Email:nikki.rogers@bristol.ac.uk
Tel: +44(0)117 9287096 (Direct)
Tel: +44(0)117 9287193 (Office)

Received on Friday, 10 December 2004 12:08:08 UTC