Low level API

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