Re: Low level API

Nikki,

1) Oops. I guess the getConceptRelativesByPath didn't register with me when 
I was working my way through the API, since it returns only an array of 
Concepts, which (as you point out) doesn't help much since there is no 
indication of distance or structure. I'm intrigued by your notion of 
supporting another XML format (which I wonder?) and will stayed tuned for 
further updates...

2) As for the use cases, Dan Brickley wrote :
>I doubt we can specify the human-readable offerings of thesaurus
>providers in such detail, beyond noting best practice conventions and
>common useful UI conventions. What we can do, though, is take these
>as use cases for evaluating the _machine_ interface defined in the SKOS
>API. We can ask ourselves whether such a UI could be built against
>any/all SKOS servers that meet the API. This opens up the prospect of
>write-once, re-use elsewhere thesaurus browsing tools...

Dan's first point, about specifying the human-readable offerings of 
thesaurus providers is not a problem, that's been done (and is being 
revised) in the appropriate national and international standards and in 
best practices. What I was trying to help do was what Dan was suggesting in 
his second point, that is, evaluating the appropriateness of the SKOS API 
for building some of those common UIs. My comments are not intended as a 
criticism of your work, this is complex stuff,  but I think there have been 
a number of problem areas mentioned where the machine interface is not yet 
up to this task.

IMHO this is (or should be) an important issue for SWAD, because it will 
affect adoption of the SKOS API. If thesaurus publishers have to support 
one API to interact with the Semantic Web, and another interface to 
interact with fully functioned thesaurus clients, then they will be 
inclined to implement _neither_. Having a single interface that will 
support a reasonably complete set of functionality (and there is a huge 
overlap) means everyone wins. For one thing, the API would be a machine 
interface that those national and international thesaurus standards (now in 
the process of being revised) would be able to endorse.

Ron
--------------------------------------
Ron Davies
Information and documentation systems consultant
Av. Baden-Powell 1  Bte 2, 1200 Brussels, Belgium
Email:  ron@rondavies.be
Tel:    +32 (0)2 770 33 51
GSM:    +32 (0)484 502 393

At 16:46 11/05/2004, NJ Rogers, Learning and Research Technology wrote:

>Hi Ron
>
>I am working as a technical developer on the SKOS API and a demo 
>implementation of it and very much welcome your input.
>
>A couple of initial points (in lieu of giving your references [1] and [3] 
>a proper read):
>
>"the client has to do a great deal of work, and send out many
>>atomic requests to be able to do certain kinds of required tasks, e.g.
>>build a useful hierarchical display format"
>
>1) We do provide (see http://www.w3.org/2001/sw/Europe/reports/thes/api/docs/)
>methods such as
>         getConceptRelativesByPath(Concept concept, Relation relation, URI 
> thesaurus, int distance)
>
>Which we describe as 'Get a list of concept relatives for a particular 
>thesaurus up to some distance.'
>
>And by 'up to some distance' we mean 'number of levels' in the sense that 
>I believe you to be talking about below.  So this avoids the need for 
>repetitive calls to the service to retrieve concepts 'clustered' around 
>some concept in the concept hierarchy. Instead, in response to these sorts 
>of service requests we intend to return sets of concepts. We haven't 
>finalised our strategy for indicating exactly how distant each result-set 
>concept is from a given point in the graph ... (And I note that this issue 
>relates to the syntax we use for encoding the response data the service 
>can send to the client. For our initial SOAP service implementation we are 
>using the soap data encoding syntax and will likely move on to include 
>support for XML as well as RDF/XML).
>
>2) You may well have already seen the use cases we're developing at 
>http://www.w3.org/2001/sw/Europe/200311/thes/Use_cases_Thes_Service.html 
>(in need of updating shortly, since I've received more contributions from 
>the community). I hadn't really imagined that client applications would 
>want to build extensive, browsable displays of concept hierarchies via the 
>network and 'on the fly' as it were. But this is an interesting point and 
>I wonder if we need to provide some harvesting capability on the service 
>as well....
>
>As I say, an initial response, thank you for your query,
>regards
>Nikki