W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2004

SKOS API

From: Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk>
Date: Tue, 11 May 2004 16:55:23 +0100
Message-ID: <350DC7048372D31197F200902773DF4C04944297@exchange11.rl.ac.uk>
To: public-esw-thes@w3.org

Hi all,

Just to explain the state of the SKOS API and the current work going on in
SWAD-E ... Dave and Nikki are currently working on a reference
implementation of the API as is, which will probably be ready by the end of
the month.  

There are a bunch of technical issues, relating to the implementation of
this API, such as the question of how to encode the data that the service
returns.  

In parallel there is a continued discussion of the SKOS API at a functional
level.  The SKOS API is intended to be a functional specification for a
thesaurus service - i.e. it defines the functionality that we require of
such a service.  

So there are two separate discussions to be made: (1) A discussion of issues
surrounding how to implement the current version of the SKOS API (techie
stuff), and (2) A discussion of how to improve the API itself for the next
version (abstract stuff).

Obviously there's going to be some overlap, but I reckon it will help if we
manage keep this distinction as clear as possible (in our minds at least).  

Al.


      

> -----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: 11 May 2004 16:13
> To: Leonard Will; public-esw-thes@w3.org
> Subject: Re: Low level API
> 
> 
> 
> Hi Leonard
> 
> > I don't think that it should be necessary to store "level" 
> information to
> > achieve this, and indeed I think that doing so would 
> complicate matters,
> > because if a concept is inserted to create a new level of 
> grouping then
> > the "levels" of all the subordinate concepts would change.
> >
> Yes, skos takes the approach of expressing broader/narrower/related 
> relationships between concepts. If we are to add what is effectively 
> harvesting functionality to the thesaurus, then we would 
> likely return skos 
> encoded data as is, from which some client app would be able 
> to build a 
> thesaurus browser if required.
> 
> If time permits we may demonstrate how this would work 
> against our own demo 
> thesaurus service implementation. For example either by 
> layering Protege on 
> top of our service for browser-based views on the data, or developing 
> prototype viewer implementations that we already have.
> 
> Nikki
> 
> 
> > Leonard Will
> > --
> > Willpower Information       (Partners: Dr Leonard D Will, 
> Sheena E Will)
> > Information Management Consultants              Tel: +44 
> (0)20 8372 0092
> > 27 Calshot Way, Enfield, Middlesex EN2 7BQ, UK. Fax: +44 
> (0)870 051 7276
> > L.Will@Willpowerinfo.co.uk               
> Sheena.Will@Willpowerinfo.co.uk
> > ---------------- <URL:http://www.willpowerinfo.co.uk/> 
> -----------------
> >
> >
> 
> 
> 
> ----------------------
> 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 Tuesday, 11 May 2004 11:56:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:52 GMT