- From: NJ Rogers, Learning and Research Technology <Nikki.Rogers@bristol.ac.uk>
- Date: Fri, 10 Dec 2004 12:05:11 -0000
- To: "Houghton,Andrew" <houghtoa@oclc.org>, public-esw-thes@w3.org
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