RE: Low level API

Hi Andy
>
> The SKOS API suffers from the same problem that previous API's
> like ASDL suffer from.  When dealing with Web services you
> need to be careful about your interface.  It's not efficient
> for a server to return a complete hierarcy.  This could amount
> to a lot of data being returned to the client.  Just like its
> not a good idea to have a "return the top terms of the thesaurus"
> request, which could wind up sending you the whole thesaurus.  In
> either case, before you could build the XML for the SOAP response
> your underlying TCP/IP connection would most likely timeout.
>
> From what I can see the SKOS API will not scale.

Thanks for the information in this email - I'll have a look at these 
references you cite.

I'd like to mention here (as earlier in this thread) that the SKOS API is 
use case driven. I believe that the SKOS API provides a good initial 
attempt at defining the basis of functionality for some thesaurus service. 
Now that service might be a web service, or it might not - it might instead 
represent a programmatic interface for some application. So we are not 
necessarily constrained by network considerations (& I would also perhaps 
throw in the word "Grid" in at this point :-)).

Should some application require a service's complete thesaurus hierarchy it 
could potentially harvest the data periodically, and store it locally in 
order to use it for whatever functionality its client app (e.g. 
browser-based thesaurus viewer) might require. [and that client app itself 
might well adhere to the SKOS API specification]. There are harvesting 
protocols that could apply here e.g. OAI (http://www.openarchives.org/).

In a different scenario, suppose some client application did not wish to be 
potentially overloaded by large response data sets from a thesaurus web 
service, well, this situation has been tackled before in the sphere of 
network search and retrieval. For example see 
http://zthes.z3950.org/srw/current.html. It is possible to develop a web 
service that can handle some notion of state such that a client may 
negotiate with the service how large a result set it is prepared to 
receive. And so on ....

Regards,
Nikki

> There was a good
> recently published paper on this subject in Cataloging & Classification
> Quaterly, volumne 37, Issue 3/4.  Matter of fact this whole issue is
> a good read, due to the wealth of thesaurus topics:
>
> Distributed Thesaurus Web Services
> Eric H. Johnson
> http://www.haworthpress.com/store/ArticleAbstract.asp?ID=34895
> HTML-based information services provide access to online information
> sources but do not make them useful for much more than viewing in a Web
> browser. There is also no cohesive cataloging or subject access scheme
> for the Internet. XML and Web services provide the framework for
> enhancing the information content of all types of data delivered over the
> Internet and for enhancing the functionality of specialized yet
> interoperable networked information retrieval applications. The
> Thesauro-Web, a proposed network of thesaurus access and navigation
> services, could provide enhanced subject access for the World Wide Web
> and enhance the functionality of information retrieval applications. The
> idea behind the Thesauro-Web is described here in detail, with examples
> of applicable XMLprotocols and descriptions of possible uses.
>
> Another good article I read recently was in JoDI volume 4, issue 4 -- New
> Applications of KOS http://jodi.ecs.soton.ac.uk/Articles/v04/i04/Binding/
>
> C. Binding, D. Tudhope: KOS at your Service: Programmatic Access to
> Knowledge Organisation Systems
> http://jodi.ecs.soton.ac.uk/Articles/v04/i04/Soergel/
>
> An interesting API approach to thesauri can been seen in Microsoft's
> Research services available in Office 2003, see:
> http://msdn.microsoft.com/office/understanding/research/default.aspx
>
> Here the API is limited to a basic query but the message returned could be
> an XHTML document which opens up the possibility to follow BT/NT/RT
> relationship in your thesaurus, but this is outside the scope of the
> Research services API.  Wouldn't it be great to have your favorite
> thesaurus available to put quality metadata into your research paper?  I
> realize that many are anti-Microsoft but the Research services API could
> be lifted and put into OpenOffice and/or other products, after all a Web
> service API is just that an API regardless of who created it.  The
> interesting aspect of this API is that it moves quality metadata creation
> down to the author. Wouldn't it also be great to have your favorite SKOS
> encoded vocabulary appear in the Research task pane?  The Research
> services API provides a working vechicle for how the Semantic Web could
> actually be useful.
>
>
> Andy.
>
> Andrew Houghton, OCLC Online Computer Library Center, Inc.
> http://www.oclc.org/about/
> http://www.oclc.org/research/staff/houghton.htm
>
>



----------------------
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 12:40:47 UTC