[Tdwg-tag] Primary Objects as XML Structures or OWL Classes

[Bob Morris]

I'm rushing off to the GISIN meeting at AGADIR and might not have much time
to respond more before midweek, or maybe even until I get back next week,
but:

0.  I _wish_ this discussion were taking place in a wiki, with RSS or email
notification,  so it is easier to follow if you cannot keep up with the
email

1.  I don't think specifications of high level things like "objects" should
be done in a serlization constraint languge such as RDF or XML Schema.
Instead, it should have something more general as the normative definition
and have _representation_ in one or more of such constraint languages. This
is the mechanism of W3C usually. Many (Most?) W3C standards have a normative
BNF definition, and one or more representations to allow implementers to
actually do business.  OMG favors UML for this, etc.There is nothing
inherently normative about, say RDF or XML Schema, for, say TaxonConcepts.
If you take the serialization language as the normative language, then in
the future you just end up having to support several serialization languages
when you find you want to extend your specification with something for which
the chosen one is insufficiently expressive. This, in fact, is what is going
on now with the cries for RDF over XML Schema. Put another way, if you
choose language L as the normative language, you are not building a
specification, but rather a set of constraints on applications written in L.
Such things do not have as long a life as actual specifications do and
mature standards bodies do not seem to use serialization languages as the
root specification language, as far as I can tell.  My conclusion is that
specifications should not be in anything like RDF or XML Schema, but in
something else---BNF is probably adequate for most TDWG standards---with
working subgroups responsible for publishing a serialization definition
implementing the standard in languages useful for one or another purpose,
e.g. LSID resolution.

Bob




On 2/17/06, Roger Hyam <roger at tdwg.org> wrote:
>
>
> Hi All,
>
> In a previous post I suggested definitions for Resolving, Searching and
> Querying from the point of view of the TAG. There has been a muted response
> which I take as meaning there aren't any strong objections to these
> definitions. We can come back to them later if need be. You can read the
> post here if you missed it:
>
>
> http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-February/000009.html
>
> I'd like to look at the implications of the first two definitions:
>
>    1. *Resolving.* This means to convert a pointer into a data object.
>       Examples would be to resolve an LSID and get back either data or
>       metadata or resolve a url and get back a web page in html.
>    2. *Searching.* This means to select a set of objects (or their
>       proxies) on the basis of the values of their properties. The
>       objects are  predefined (implicitly part of the call) and we are
>       simply looking for them. An example would be finding pages on Google.
>
> Both these definitions imply the existence of data 'Objects' or
> 'Structures' that are understood by the clients when they are received. The
> kinds of objects that jump to mind are Specimens, TaxonNames, TaxonConcepts,
> NaturalCollections, Collectors, Publications, People,  Expeditions etc etc.
> A piece of client software should be able to know what to do with an object
> when it gets - how to display it to the user or map it to a db etc.
>
> My two leading questions are:
>
>    1. *Should there be commonality to all the objects?* If yes - what
>    should it be? XML Schema location or OWL Class or something else? If no -
>    then how should clients handle new objects dynamically - or shouldn't they
>    be doing that kind of thing.
>    2. *Should we have multiple ways of representing the SAME objects?*
>    e.g. Should there be only one way to encode a Specimen or should it
>    be possible to have several encodings running in parallel. If there is only
>    one way how do we handle upgrades (where we have to run two types of
>    encoding together during the roll out of the new one) AND how do we reach
>    consensus on the 'perfect' way of encoding each and every object in our
>    domain?
>
> The answers I have for my leading questions are:
>
>    1. Yes - We should have some commonality between objects or it will
>    be really difficult to write client code - but what that commonality is has
>    to be decided.
>     2. Yes - The architecture has to handle multiple versions/ways of
>    encoding any particular object type because any one version is not likely to
>    be ideal for everyone forever.
>
> Are the two conclusions I come to here reasonable? Is this too high level
> and not making any sense?
>
> I'd be grateful for your thoughts on this,
>
> Roger
>
>
> --
>
> -------------------------------------
>  Roger Hyam
>  Technical Architect
>  Taxonomic Databases Working Group
> -------------------------------------
>  http://www.tdwg.org
>  roger at tdwg.org
>  +44 1578 722782
> -------------------------------------
>
>
> _______________________________________________
> Tdwg-tag mailing list
> Tdwg-tag at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20060217/b104542e/attachment.html