<!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">
Hi Rob,<br>
<br>
Thanks for your contribution. My comments below:<br>
<br>
Robert Gales wrote:
<blockquote cite="mid44216871.7070302@ku.edu" type="cite">Just
thoughts/comments on the use of XML Schema for validating RDF
documents.
<br>
<br>
I'm afraid that by using XML Schema to validate RDF documents, we would
be creating unnecessary constraints on the system. Some services may
want to serve data in formats other than RDF/XML, for example N-Triple
or Turtle for various reasons. Neither of these would be able to be
validated by an XML Schema. For example, I've been working on indexing
large quantities of data represented as RDF using standard IR
techniques. N-Triple has distinct benefits over other representations
because its grammar is trivial. Another benefit of N-Triple is that
one can use simple concatenation to build a model without being
required to use an in memory model through an RDF library such as
Jena. For example, I can build a large single document containing
N-Triples about millions of resources. The index maintains file
position and size for each resource indexed. The benefit of using
N-Triple is that upon querying, I can simple use fast random access to
the file based on the position and size stored in the index to read in
chunks of N-Triple based on the size and immediately start streaming
the results across the wire.
<br>
<br>
</blockquote>
This sounds like really interesting work! And it illustrates why what I
am proposing is useful. If you wanted to introduce data into your index
from arbitrary data providers would you prefer:<br>
<ol>
<li>RDF as N-Triple: I guess this would be your favorite but it is
unlikely that all data sources would give it in this - though some
might.</li>
<li>RDF as XML: I guess this is second best as you can convert it to
N-Triple then append it to your index. You don't care how the
serialization into XML is done as a library can read it and convert it
so long as it is valid.<br>
</li>
<li>XML according to some arbitrary schema: This is what you will get
today. This is a nightmare as you would have to work out a mapping from
the 'semantics' that may be in the document structure or schema into
RDF triples.</li>
</ol>
What I am suggesting is that publishers who want to do 3 (which is a
potential nightmare to consumers and indexers) could, by careful schema
design, make themselves into 2 above - which makes them interoperable
with an RDF world.<br>
<br>
<blockquote cite="mid44216871.7070302@ku.edu" type="cite">With the
additional constraint of using only RDF/XML as the output format, the
above indexer example would either need to custom serialize N-Tripe
-> RDF/XML or use a library to read it into an in-memory model to
serialize it as RDF/XML.
<br>
<br>
</blockquote>
If you want to return stuff from your index as N-Triple then your
customers are going to have to be able to handle it. If they can't
handle it you won't get any customers. If you serialize just the query
results as RDF/XML then it may be a lot easier for people to consume.
Perhaps you could offer a choice. I would suggest that if your
customers wanted to have a particular 'avowed' serialization of the
RDF then they should do it themselves but that it might be easier to
do from XML than N-Triple.<br>
<blockquote cite="mid44216871.7070302@ku.edu" type="cite">Another
concern is that we will be reducing any serialization potential we have
from standard libraries. Jena, Redland, SemWeb, or any other library
that can produce and consume RDF is not likely to produce RDF/XML in
the same format. Producers of RDF now will not only be required to use
RDF/XML as opposed to other formats such as N-Triple, but will be
required to write custom serialization code to translate the in-memory
model for the library of their choice into the structured RDF response
that fits the XML Schema. It seems to me, we are really removing one
of the technical benefits of using RDF. Services and consumers really
should not need to be concerned about the specific structure of the
bits of RDF across the wire so long as its valid RDF.
<br>
</blockquote>
I agree with you fully but we are starting from scratch here and we
have to take everyone with us - and see who we can pick up along the
way. I get a lot of messages from people (written, verbal and body
language) saying that they reckon doing things in RDF is dangerous
because "it will never work". They may be right or they may be sticking
with what they are comfortable with. If I can say "OK, forget about
RDF, just make your XML look like this (which happens to be valid RDF)"
then everyone can come to the same party. <br>
<ol>
<li>If you 'speak' RDF/XML then anyone on the network can understand
you. You can do this with any old script.<br>
</li>
<li>If you can understand RDF/XML you can listen to anyone on the
network. You can do this with any old RDF parser...<br>
</li>
<li>If you don't understand RDF/XML then you will have to put some
effort in to understand everyone but you will be able to understand a
subset of people who use 'avowed' serializations that you care about.</li>
</ol>
What is important here is that if RDF really is a terrible thing then
the consumers of data in category 3 will grow in number and nobody
will bother with triples in a few years. On the other hand if RDF is so
great then consumers in category 2 will die out. Darwin kind of had it
right for these things. I hope that the use of 'avowed' serializations
will just let nature take its course. I sure as hell don't want the
responsibility :)<br>
<blockquote cite="mid44216871.7070302@ku.edu" type="cite">In my humble
opinion, any constraints and validation should be either at the level
of the ontology (OWL-Lite, OWL-DL, RDFS/OWL) or through a reasoner that
can be packaged and distributed for use within any application that
desires to utilize our products.
<br>
<br>
</blockquote>
Yes. Ideally that is how it should be done.If we have a basic RDFS
ontology for the shared objects then people can extend this for their
own purposes with OWL ontologies. We will never get agreement on a
complete OWL ontology for the whole domain for sociological as well as
technical reasons.<br>
<br>
I think my mistake here is calling this a 'generic' solution. It is a
bridging technology.<br>
<br>
Does this make sense?<br>
<br>
Roger<br>
<br>
<br>
<blockquote cite="mid44216871.7070302@ku.edu" type="cite">Cheers,
<br>
Rob
<br>
<br>
Roger Hyam wrote:
<br>
<blockquote type="cite">Hi Everyone,
<br>
<br>
I am cross posting this to the TCS list and the TAG list because it is
relevant to both but responses should fall neatly into things to do
with nomenclature (for the TCS list) and things to do with technology -
for the TAG list. The bit about avowed serializations of RDF below are
TAG relevant.
<br>
<br>
The move towards using LSIDs and the implied use of RDF for metadata
has lead to the question: "Can we do TCS is RDF?". I have put together
a package of files to encode the TaxonName part of TCS as an RDF
vocabulary. It is not 100% complete but could form the basis of a
solution.
<br>
<br>
You can download it here:
<br>
<a class="moz-txt-link-freetext" href="http://biodiv.hyam.net/schemas/TCS_RDF/tcs_rdf_examples.zip">http://biodiv.hyam.net/schemas/TCS_RDF/tcs_rdf_examples.zip</a>
<br>
<br>
For the impatient you can see a summary of the vocabulary here:
<a class="moz-txt-link-freetext" href="http://biodiv.hyam.net/schemas/TCS_RDF/TaxonNames.html">http://biodiv.hyam.net/schemas/TCS_RDF/TaxonNames.html</a>
<br>
<br>
and an example xml document here:
<a class="moz-txt-link-freetext" href="http://biodiv.hyam.net/schemas/TCS_RDF/instance.xml">http://biodiv.hyam.net/schemas/TCS_RDF/instance.xml</a>
<br>
<br>
It has actually been quite easy (though time consuming) to represent
the semantics in the TCS XML Schema as RDF. Generally elements within
the TaxonName element have become properties of the TaxonName class
with some minor name changes. Several other classes were needed to
represent NomenclaturalNotes and Typification events. The only
difficult part was with Typification. A nomenclatural type is both a
property of a name and, if it is a lectotype, a separate object that
merely references a type and a name. The result is a compromise in an
object that can be embedded as a property. I use instances for
controlled vocabularies that may be controversial or may not.
<br>
<br>
What is lost in only using RDFS is control over validation. It is not
possible to specify that certain combinations of properties are
permissible and certain not. There are two approaches to adding more
'validation':
<br>
<br>
<br>
OWL Ontologies
<br>
<br>
An OWL ontology could be built that makes assertions about the items in
the RDF ontology. It would be possible to use necessary and sufficient
properties to assert that instances of TaxonName are valid members of
an OWL class for BotanicalSubspeciesName for example. In fact far more
control could be introduced in this way than is present in the current
XML Schema. What is important to note is that any such OWL ontology
could be separate from the common vocabulary suggested here. Different
users could develop their own ontologies for their own purposes. This
is a good thing as it is probably impossible to come up with a single,
agreed ontology that handles the full complexity of the domain.
<br>
<br>
I would argue strongly that we should not build a single central
ontology that summarizes all we know about nomenclature - we couldn't
do it within my lifetime :)
<br>
<br>
<br>
Avowed Serializations
<br>
<br>
Because RDF can be serialized as XML it is possible for an XML document
to both validate against an XML Schema AND be valid RDF. This may be a
useful generic solution so I'll explain it here in an attempt to make
it accessible to those not familiar with the technology.
<br>
<br>
The same RDF data can be serialized in XML in many ways and different
code libraries will do it differently though all code libraries can
read the serializations produced by others. It is possible to pick one
of the ways of serializing a particular set of RDF data and design a
XML Schema to validate the resulting structure. I am stuck for a way to
describe this so I am going to use the term 'avowed serialization'
(Avowed means 'openly declared') as opposed to 'arbitrary
serialization'. This is the approach taken by the prismstandard.org
<a class="moz-txt-link-rfc2396E" href="http://www.prismstandard.org"><http://www.prismstandard.org></a>group for their standard and it
gives a number of benefits as a bridging technology:
<br>
<br>
1. Publishing applications that are not RDF aware (even simple
<br>
scripts) can produce regular XML Schema validated XML documents
<br>
that just happen to also be RDF compliant.
<br>
2. Consuming applications can assume that all data is just RDF and
<br>
not worry about the particular XML Schema used. These are the
<br>
applications that are likely to have to merge different kinds of
<br>
data from different suppliers so they benefit most from treating
<br>
it like RDF.
<br>
3. Because it is regular structured XML it can be transformed using
<br>
XSLT into other document formats such as 'legacy' non-RDF
<br>
compliant structures - if required.
<br>
<br>
There is one direction that data would not flow without some effort.
The same data published in an arbitrary serialization rather than the
avowed one could be transformed, probably via several XSLT steps, into
the avowed serialization and therefore made available to legacy
applications using 3 above. This may not be worth the bother or may be
useful. Some of the code involved would be generic to all
transformations so may not be too great. It would certainly be possible
for restricted data sets.
<br>
<br>
To demonstrate this instance.xml is included in the package along with
avowed.xsd and two supporting files. instance.xml will validate against
avowed.xsd and parse correctly in the w3c RDF parser.
<br>
<br>
I have not provided XSLT to convert instance.xml to the TCS standard
format though I believe it could be done quite easily if required.
Converting arbitrary documents from the current TCS to the structure
represented in avowed.xsd would be more tricky but feasible and
certainly possible for restricted uses of the schema that are typical
from individual data suppliers.
<br>
<br>
<br>
Contents
<br>
<br>
This is what the files in this package are:
<br>
<br>
README.txt = this file
<br>
TaxonNames.rdfs = An RDF vocabulary that represents TCS TaxonNames
object.
<br>
TaxonNames.html = Documentation from TaxonNames.rdfs - much more
readable.
<br>
instance.xml = an example of an XML document that is RDF compliant use
of the vocabulary and XML Schema compliant.
<br>
avowed.xsd = XML Schema that instance.xml validates against.
<br>
dc.xsd = XML Schema that is used by avowed.xsd.
<br>
taxonnames.xsd = XML Schema that is used by avowed.xsd.
<br>
rdf2html.css = the style formatting for TaxonNames.html
<br>
rdfs2html.xsl = XSLT style sheet to generate docs from TaxonNames.rdfs
<br>
tcs_1.01.xsd = the TCS XML Schema for reference.
<br>
<br>
<br>
Needs for other Vocabularies
<br>
<br>
What is obvious looking at the vocabulary for TaxonNames here is that
we need vocabularies for people, teams of people, literature and
specimens as soon as possible.
<br>
<br>
<br>
Need for conventions
<br>
<br>
In order for all exchanged objects to be discoverable in a reasonable
way we need to have conventions on the use of rdfs:label for Classes
and Properties and dc:title for instances.
<br>
<br>
The namespaces used in these examples are fantasy as we have not
finalized them yet.
<br>
<br>
<br>
Minor changes in TCS
<br>
<br>
There are a few points where I have intentionally not followed TCS 1.01
(there are probably others where it is accidental).
<br>
<br>
* basionym is a direct pointer to a TaxonName rather than a
<br>
NomenclaturalNote. I couldn't see why it was a nomenclatural note
<br>
in the 1.01 version as it is a simple pointer to a name.
<br>
* changed name of genus element to genusEpithet property. The
<br>
contents of the element are not to be used alone and are not a
<br>
genus name in themselves (uninomial should be used in this case)
<br>
so genusEpithet is more appropriate - even if it is not common
<br>
English usage.
<br>
* Addition of referenceTo property. The vocabulary may be used to
<br>
mark up an occurrence of a name that is not a publishing of a new
<br>
name. In these cases the thing being marked up is actually a
<br>
pointer to another object, either a TaxonName issued by a
<br>
nomenclator or a TaxonConcept. In these cases we need to have a
<br>
reference field. Here is an example (assuming namespace)
<br>
<TaxonName
<br>
referenceTo="urn:lsid:example.com:myconcepts:1234"><genusEpithet>Bellis</genusEpithet><specificEpithet>perennis</specificEpithet></TaxonName>
<br>
This could possibly appear in a XHTML document for example.
<br>
<br>
<br>
Comments Please
<br>
<br>
All this amounts to a complex suggestion of how things could be done.
i.e. we develop central vocabularies that go no further than RDFS but
permit exchange and validation of data using avowed serializations and
OWL ontologies.
<br>
<br>
What do you think?
<br>
<br>
Roger
<br>
<br>
<br>
-- <br>
<br>
-------------------------------------
<br>
Roger Hyam
<br>
Technical Architect
<br>
Taxonomic Databases Working Group
<br>
-------------------------------------
<br>
<a class="moz-txt-link-freetext" href="http://www.tdwg.org">http://www.tdwg.org</a>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:roger@tdwg.org">roger@tdwg.org</a>
<br>
+44 1578 722782
<br>
-------------------------------------
<br>
<br>
<br>
------------------------------------------------------------------------
<br>
<br>
_______________________________________________
<br>
Tdwg-tag mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Tdwg-tag@lists.tdwg.org">Tdwg-tag@lists.tdwg.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org">http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org</a>
<br>
</blockquote>
<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>