Best practice in binding service instances to vocabularies deployed as services

Having been watching this and other threads for many years, I'm looking 
for a scalable way of binding a vocabulary to a service, which means of 
course binding a vocabulary to a single element or property of a message 
type.

I see that SPARQL has emerged in a few recent discussions, but it is in 
widespread use in the development of emerging standards?

To put this into perspectice - static XML files (OWL or enumerations in 
XML schema) arent sufficient. One case in point is "species taxonomy" 
where there are potentially millions of valid terms,
they will change - maybe daily! - and there are many subsets that will 
be in use within particular services - e..g Mr & Mrs Escargot's fabulous 
mollusc museum collection...

We have other instances - for example a gazetteer, where the 
vocabularies may be bound to a registered collection of geographic 
objects. In this case, we need to support a geographic search interface, 
but we can (and arguable should) support one or more pure "vocabulary' 
or ontology views. What should these be? Is there an arguable case for 
any one interface?

The criteria for "being useful" includes:
1) must allow for (in query and response) taxonomies (hierarchical 
vocabularies) at the very least,  with an ability to handle richer 
ontologies desirable
2) Must allow, in practice, "registry" - eg ebXML -  implementations for 
the management of vocabulary content (this may simply be a matter of 
expecting such registires to offer a single alternative interface)
3) Must allow trivial cases to be supported by static files
4) Must allow deployment as a web service
5) Must support caching within clients of high-volume-use subsets of 
vocabularies - e.g. the static top level Species classification
6) Must be stable enough, and governed by an international standards 
body, to be used within other international standards
7) Must have reference implementations available for web services
8) Must have evidence of adoption and deployment by standards agencies, 
or a statement of commitment from the governing body that it is the 
recommended solution
9) if multiple complementary mechanisms, where should one be used over 
the other?

Maybe such a thing remains elusive, but I have a feeling we are getting 
closer.

Could anyone provide or point me to a summary of best practice in this 
regard? An argued case for adoption of a particular mechanism (or small 
complementary set of mechanisms)

Regards
Rob Atkinson

Received on Sunday, 4 June 2006 01:24:34 UTC