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

:) It seems Nikki & I are cosmically aligned ... I was just playing around
with writing a 'SKOS Core profile for SRW' which is at:

http://esw.w3.org/topic/SkosDev/SrwProfile

+1 on everything Nikki said.  The API is abstract, and so attempts to define
at an abstract lebel the set of functionalities that should be implemented
by a SKOS web service.  

The main limitation of SRW (if I've understood it correctly) in respect of
concept schemes is that semantic expansion around a focus concept can only
be done one layer at a time.  One of the most important requirements for a
SKOS web servise is to perform some sort of parameterised expansion, so that
clients could get any size chunks of a concept scheme. 

The other point is what Nikki said about SRW and XML ... we don't
necessarily want to be tied to delivering XML constrained by an XML schema
or DTD as message payload (other options are SOAP encoded objects and RDF).

Cheers,

Al.


---
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440



> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of NJ 
> Rogers, Learning
> and Research Technology
> Sent: 10 December 2004 12:08
> To: Houghton,Andrew; public-esw-thes@w3.org
> Subject: 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:37:26 UTC