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
>
Pleasure to be cosmically aligned with you Al :-) At first glance this SRW 
profile effort of yours looks good, I'll take a closer look when i get a 
chance & refresh my memory of SRW at the same time.

> +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.
>
Well, maybe this needs further discussion. Dave & I tackled this issue 
while developing the SKOS API and came up with an (extremely) tentative 
solution: 'ConceptRelatives' (see 
http://www.w3.org/2001/sw/Europe/reports/thes/api/docs/ and follow via the 
'ConceptRelatives' link).
The idea of introducing a new (non-SKOS standard) ConceptRelatives object 
is so that a single web service operation (& this should include SRW) can 
*return an array of objects from which a client app can effectively 
recreate a chunk of a concept scheme*.
A ConceptRelatives object contains
- an array of Concepts
- a distance (e.g. 1, 2, 3 etc) away from the focus concept
- a Relation (in order to indicate whether the array of Concepts is 
broader/narrower etc than the focus concept).
Thus an array of ConceptRelatives can contain whole sets of Concepts data 
from which to reconstruct a Concept scheme.

This approach has obviously never been tested in the wild! I don't even 
know if it should be considered legitimate as it is not based on SKOS 
directly - Dave and I left ConceptRelatives among our list of 'issues' 
published at project exit time. There are also possibly some details to 
smooth out for example re representing the granularity of broader/narrower 
etc properties and their sub-properties....

Anyway, in a sense we actually looked more to providing for 
SRW/XML-oriented web service apps by following this route. What we didn't 
have time to develop was a good approach for exchanging RDF encoded data 
for RDF queries via the web service. This latter use case is worth some 
major attention in my opinion and I look set to give it some during one of 
my current projects, which is providing a web service for a JISC shared 
service here in the UK.

Thanks
Nikki





> 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)
>>



----------------------
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 13:14:07 UTC