<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hi Bob,<br>
<br>
<blockquote
cite="mid16957b040602170617p59fb1b23u1f2f04f00c53a9b2@mail.gmail.com"
type="cite">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:<br>
<br>
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 <br>
</blockquote>
The way I was planning on running the TAG discussions was to have
'discussions' on the mailing list and summarize them to the wiki. The
motivation behind this is to work towards the wiki being a readable
document for the uninitiated. It should not be necessary for some one
coming new to a field to have to read all the discussions that have
taken place to reach a conclusion. These discussions should be
available but it is the job of an editor/facilitator to create a
readable narrative from possibly wandering dialog.<br>
<br>
The wiki is here: <a class="moz-txt-link-freetext" href="http://www.tdwg.hyam.net/twiki/bin/view/TAG">http://www.tdwg.hyam.net/twiki/bin/view/TAG</a><br>
<br>
The URL will change at some point in the next few months but I will
make sure all URLs forward to the appropriate place on the new server.
There is no RSS feed on it at present I'll see about setting one up
either now or when we move it to the main server.<br>
<br>
The mailing list archive is here:
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/">http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/</a> so any thread
can be followed and resurrected at any time.<br>
<br>
I take on board what you are saying though and will try and create
links between the wiki and list archive.<br>
<blockquote
cite="mid16957b040602170617p59fb1b23u1f2f04f00c53a9b2@mail.gmail.com"
type="cite">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.<br>
<br>
</blockquote>
Yes I think you are right. We should be specifying our objects in a
high level
'language' like UML (not so sure about BNF but I am not so familiar
with it) . There has been talk about OWL Lite as a subset of UML. This
was
actually the next topic I was going to suggest and I'll kick of a
thread on it soon if no one else does.<br>
<br>
Can I take it from your reply that you think:<br>
<ol>
<li>There should be
commonality between all TDWG 'objects' and that that commonality should
be their specification in UML/BNF/Other technology? (Yes to my question
1).</li>
<li>Their should be alternative ways to serialize these objects. Some
of the
serialization may support different aspects of the objects (Yes to my
question 2). </li>
<li>XML Schema or RDF/S are not appropriate ways to define such
objects</li>
</ol>
Have I read this correctly? <br>
<br>
Roger<br>
<br>
<br>
<blockquote
cite="mid16957b040602170617p59fb1b23u1f2f04f00c53a9b2@mail.gmail.com"
type="cite">Bob<br>
<br>
<br>
<br>
<br>
<div><span class="gmail_quote">On 2/17/06, <b
class="gmail_sendername">Roger Hyam</b> <<a
href="mailto:roger@tdwg.org">roger@tdwg.org</a>> wrote:</span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Hi All,<br>
<br>
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:<br>
<br>
<a
href="http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-February/000009.html"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-February/000009.html
</a><br>
<br>
I'd like to look at the implications of the first two definitions:<br>
<pre> 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.
</pre>
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.<br>
<br>
My two leading questions are:<br>
<ol>
<li><b>Should there be commonality to all the objects?</b> 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.</li>
<li><b>Should we have multiple ways of representing the SAME
objects?</b>
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?</li>
</ol>
The answers I have for my leading questions are:<br>
<ol>
<li>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.<br>
</li>
<li>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.<br>
</li>
</ol>
Are the two conclusions I come to here reasonable? Is this too high
level and not making any sense?<br>
<br>
I'd be grateful for your thoughts on this,<br>
<br>
Roger<br>
<br>
<br>
<pre cols="72">--
-------------------------------------
Roger Hyam
Technical Architect
Taxonomic Databases Working Group
-------------------------------------
<a href="http://www.tdwg.org" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">
http://www.tdwg.org</a>
<a href="mailto:roger@tdwg.org" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">roger@tdwg.org</a>
+44 1578 722782
-------------------------------------
</pre>
<br>
_______________________________________________<br>
Tdwg-tag mailing list<br>
<a onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:Tdwg-tag@lists.tdwg.org">Tdwg-tag@lists.tdwg.org</a><br>
<a onclick="return top.js.OpenExtLink(window,event,this)"
href="http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org"
target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org</a><br>
<br>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------
Roger Hyam
Technical Architect
Taxonomic Databases Working Group
-------------------------------------
<a class="moz-txt-link-freetext" href="http://www.tdwg.org">http://www.tdwg.org</a>
<a class="moz-txt-link-abbreviated" href="mailto:roger@tdwg.org">roger@tdwg.org</a>
+44 1578 722782
-------------------------------------
</pre>
</body>
</html>