Back to SkosDev

Meeting at ILRT, attending Dave Beckett, Nikki Rogers, Alistair Miles, Charles McAthieNeville.

SKOS Web Service API & Implementation Issues

Status of implementation ...

Design is partially implemented, live service.

Finish off the API, at least 50% done.

RDFQuery method to add ... what form for results?

Bindings or triples? Maybe go to different method forms ... bindings, graph, plus parameter for serialisation syntax?

Some service methods should be done document literal style ... ? (Cf. WSI)

[Long explanation of difference between RPC encoding style and doc/lit style service after Al get's confused ...]

Maybe have some methods in API return RPC encoding, some doc/lit style.

ACTION: Dave & Nikki to experiment with one doc/lit encoded method ... e.g. the 'RDFQuery' method.

Testing of service against the data sets available e.g. GEMET .

(Dave and PShab experimented with GEMET, comparing GEMET native browser tool with SKOS WS)

Dave's Python test client works!!!!

Documentation for future development!!!

Nikki: Sesame is a bit of a nightmare to install, lots of configuration.

Chaals: Nikki to write up configuration documentation.

Mention of inferencing in the backend ... Al mentions the smooshing rules for SKOS.

Nikki's summary of major actions is:

Implement the RDFQuery method (as doc/lit).
Document installation (so web service is out of the box).
Document the nuts and bolts (for developers i.e. how to implement a plugin for a different backend).
Implement inferencing/multilingual/classification schemes/mapping? (Already done ...)

Discussion of different backends ... cwm? joseki? redland? September timescale for extra bits we still fancy doing ...

Jose Ramon interested in implementing jena backend?

ACTION: Chaals to buzz Jose Ramon on jena backend

Alternatives for client implementation ...

Chaals mentions CCF demo (Dewey, Dundee) CCF Pad

Chaals mentions issue for SKOS-Core prefLabel and prefSymbol same prop with datatype.

Versioning (Schema, API)

SKOS Schema Versioning

Chaals suggests ... versioning the namespace. Add owl:sameAs to link between versions if appropriate.

Al remembers Danbri is for NO VERSIONING of namespace, and allowing schema to evolve in situ.

Chaals says don't change the meaning of a term without changing the URI.

Al wants to use the status schema for SKOS that is used in FOAF, with addition of 'deprecated' status.

Chaals: OWL has built in versioning stuff.

Al sees the OWL versioning stuff and likes it.

Agreed to use OWL for versioning of terms in SKOS schemas, but NO VERSIONING of the whole schemas themselved.

API Versioning

Versioning entire API (opposite approach to schemas) e.g. with service having 'getVersion' method.

Chaals talks about using OWL versioning stuff to talk about API versioning relationships.

OWL-S version of API description?

Development Process Management

Schema design management

Whoever has write access to the base docs is in charge.

Al refers to design proposal see SkosDev/ChangeProcess.

Nikki mentions Request Tracker (RT).

Dave suggests using wiki instead for e.g. allocation.

Chaals has a coughing fit.

Dave has same problem with Turtle. Chaals with EARL.

Make sure public-esw-thes list as focus for devs.

ACTION: make sure people know how to request changes.

ACTION: Al sends message to SWBP for involvement in SKOS dev.

ACTION: Al look OWL versioning properties and deprecated class et.c, use top concept thing as an example.

API design management

Whoever has write access to the base docs is in charge.

Source stay on ILRT CVS server.

ACTION: Dave, Nikki to implement versioning .. ?

Al wants discrete, stable intermediate versions.

WSDL file is central reference point for design of API ... ?

Chaals says no, talk about 'version 07092004, link to WSDL description, java class etc.'

AGREED: Freeze points for API, identifier for that version is date of freeze, also make sure links to all source and doc for that version is maintained.

ACTION: Freeze sometime in next month or two, at discretion of Nikki and Dave.