Re: Low level API

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



--On Tuesday, May 11, 2004 16:03:39 +0200 Ron Davies <ron@rondavies.be> 
wrote:

> The SKOS API appears to me to be pitched at a very low level. What I mean
> is that 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 to allow an end user to browse
> a thesaurus. Hierarchical displays are used in a wide number of thesauri
> of different styles.
>
> Let me provide an example. Suppose we want to build a browsable
> hierarchical display like found in the AAT hierarchy display for Chairs
> [1]. (Incidentally similar kinds of displays are also provided for other
> kinds of thesauri, for instance see Plant products in AGROVOC [2]). My
> math skills are not very strong, but if I understand the SKOS API
> correctly, I think this requires 53 separate calls to getConceptRelatives
> (and what is worse probably the equivalent of 53 separate SQL queries in
> the underlying thesaurus system).
>
> Contrast the SKOS API with the ADL API [3], where calls can return a
> large quantity of information to the client in a single network request.
> More importantly, a compound call like that can probably be supported
> with two SQL statements on the thesaurus system side. Why? In thesauri
> that support hierarchical displays, it is common that a notational system
> is used (at least internally) which is expressive of not only place in
> the hierarchy but number of levels, or alternatively that level
> information is stored explicitly within the record for each concept. If
> the thesaurus server has this thesaurus-specific knowledge, supplying all
> the terms lower in the hierarchy to five levels, for example, could
> conceivably be done with a single SQL statement. By relying on more
> processing on the server and using a higher level API, the performance in
> terms of the time required to return the information to build the
> hierarchical display could, I think, be vastly reduced. See also the
> comments of Binney and Tudhope [4] when looking at this problem of
> hierarchical displays in the AAT supporting the notion of compound API
> calls.
>
> Now, there may be very good reasons for this low-level API approach of
> which I am not aware. My question is this: will this not result in some
> extremely slow response  in certain important contexts relative to what a
> composite API could provide?
>
> Ron
>
> [1] AAT hierarchy for "chairs"
> http://www.getty.edu/vow/AATHierarchy?find=chairs&logic=AND&note=&page=1&
> subjectid=300038131 [2] AGROVOC http://www.fao.org/agrovoc/
> [3] ADL Thesaurus Protocol
> http://alexandria.sdc.ucsb.edu/%7Egjanee/thesaurus/specification.html [4]
> See Binney and Tudhope's comments on a Service oriented approach in
> http://jodi.ecs.soton.ac.uk/Articles/v04/i04/Binding/#5.1
>
>
> 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
>
>
>
>



----------------------
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 10:54:25 UTC