[Tdwg-tag] RDF instead of xml schema
Donald Hobern
dhobern at gbif.org
Sat Mar 25 10:17:38 CET 2006
What I somehow still failed to say clearly at the end of my previous post
was that "RDF technologies are an excellent way to do this... BUT we may
well have other mechanisms we could use". My real interests are not in
getting RDF adopted but in finding a really good solution to all our
modelling problems and answering the three needs I gave in my previous post.
I have two options that I see at this stage as plausible ways to do this.
In both cases, I would of course recommend that we model our objects using a
more neutral language such as UML and then generate the encoding models we
actually use. After that here are the two options I see (not in any order
of priority).
- - - - -
1. The "new-style" RDF-based ontology approach
I see the direct use of plain RDF as the encoding as roughly equivalent to
using an assembler as our programming language. We would be able to do
absolutely everything we would like to do but there is no real need for the
pain and ugliness of such a low-level representation. I understand the
natural response of shock when people are presented with a mass of RDF
triples.
I would much rather adopt a higher-level standard (probably OWL Lite) to
allow us to represent the same information in a more familiar and friendly
way and make our underlying classes clearer.
I believe that the main problems from use of RDF will arise from attempts to
manage inferences based on the underlying triples rather than in the basic
modelling of objects and exchanging and consuming data encoded in RDF or
RDF-based languages. For me, the main reasons for considering RDF are all
in this second (easier) set of functions, and therefore I'm not really
worried by the technology. If the tools mature and we can subsequently use
inferential approaches (and exploit the power of SPARQL, etc.) then we will
be in an excellent position to benefit - otherwise nothing is lost.
Despite the doubts that met this approach last week, I still tend to think
that we should consider the option of using an RDF (OWL Lite) approach but
at the same time to support the use of XML schema models which conform to
valid subsets of our RDF models. This doesn't seem hard (although I have
been too busy this week to look closely at what Roger has done in this area)
and would immediately mean that the less IT-oriented members of our
community would be able to continue working with the tools they have already
got used to.
- - - - -
2. The modified "new-style" XML schema approach
In my opinion, the power present in the DiGIR family of protocols and
particularly TAPIR, when combined with conceptual schemas such as Darwin
Core, is enormous. The developers of DiGIR and Darwin Core produced a model
which has most of the strengths I am looking for in my previous post, but
uses the XML schema concept of substitution groups. It supports extension
in a way that is very like RDF. Its biggest weakness is that it does not
provide any ontological underpinnings of any kind. Neither DiGIR nor Darwin
Core makes any commitments regarding the class of object described in the
records returned. DiGIR provides a generic query language. Darwin Core
provides a set of useful descriptors. I could use Darwin Core to encode
data on a collection of stamps illustrating plants and animals
(ScientificName, Country, CollectionDay, etc.). We need the ability to
identify what sort of objects are being described. I gave a long and
confusing presentation at the TDWG meeting in Christchurch which was my
first attempt to explain this - I'm not sure anyone had a clue what I was
trying to say). See:
http://www.tdwg.org/2004meet/EV/TDWG_2004_Papers_Hobern_4.zip
We also had real problems applying DiGIR to ABCD because substitution groups
will not work with complex documents like ABCD.
However we could simply carry out some fairly simple modifications to our
existing XML schemas and solve these problems. We would need to do the
following:
* Determine a basic ontology of biodiversity data objects (Specimen,
Locality, Character, etc.) and some of their fundamental relationships
(collectedAt, hasCharacter, etc.)
* Restructure our current schemas so they each schema is a collection of
descriptive properties for one of these classes (perhaps a substitution
group for properties for each class - like GML?) and a container element
representing an instance of the class (and holding a collection of
descriptive properties for the class). Note that some property elements
would be RDF-like references to other objects (e.g. <collectedAt
ref="locality1"> or inline versions of such objects (e.g.
<collectedAt></location></collectedAt>.
* Enhance TAPIR so that each resource identifies itself as returning objects
from one of the standard classes (rather than untyped records)
I suspect that the structure of TCS and SDD would make this really easy in
those cases. ABCD would need to be split into classes such as Unit,
GatheringEvent, Locality, Collection and Collector rather than having
everything presented as nested properties of a Unit, but most of the work
would survive quite cleanly.
This approach would allow us to extend the properties for any class just as
easily as we can Darwin Core. We could keep using TAPIR as our search
protocol almost unchanged.
- - - - -
I am sure that there are other options but each of these seems a fairly easy
and powerful development from where TDWG has already gone. The second is
much closer to what has been done in the past (although it still represents
a more object-oriented approach instead of the current document-oriented
one). However I am not sure what we gain at that stage from not simply
using OWL Lite for the models.
Anyway, I hope this clarifies where I am coming from.
Donald
---------------------------------------------------------------
Donald Hobern (dhobern at gbif.org)
Programme Officer for Data Access and Database Interoperability
Global Biodiversity Information Facility Secretariat
Universitetsparken 15, DK-2100 Copenhagen, Denmark
Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480
---------------------------------------------------------------
Donald Hobern wrote:
> Gregor,
>
> I can understand your angst, but I would like to suggest that XML schema
> actually only really provides good support for some aspects of OO
modelling.
> Extending classes is a real problem.
>
> A data model encoded in RDF can still make use of an ontology language to
> provide greater rigour in the way that objects are defined.
>
> As was indicated in some of the earlier messages here, it is even possible
> to put together a data model which looks fundamentally just the same as
one
> defined using XML schema but which is using RDF technologies under the
> covers and which consequently is easier to extend than XML schema.
>
> For me however the biggest factors of importance in a revision of our data
> models would be:
>
> 1. A cleaner separation between different object classes (not all
versioned
> in a single schema).
>
> 2. A good model to support easy extension (using a multiple inheritance
> approach) so that different (potentially overlapping) communities can add
> extra information in the ways that best suit them.
>
> 3. An underlying ontology that is sufficient for us at least to identify
the
> object class of each record.
>
> RDF technologies are an excellent way to do this. GML has managed to
> produce many of the same features, but has probably done so largely by
> replicating the essentials of RDF modelling.
>
> Thanks,
>
> Donald
>
> ---------------------------------------------------------------
> Donald Hobern (dhobern at gbif.org)
> Programme Officer for Data Access and Database Interoperability
> Global Biodiversity Information Facility Secretariat
> Universitetsparken 15, DK-2100 Copenhagen, Denmark
> Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480
> ---------------------------------------------------------------
>
>
> -----Original Message-----
> From: Tdwg-tag-bounces at lists.tdwg.org
> [mailto:Tdwg-tag-bounces at lists.tdwg.org] On Behalf Of Gregor Hagedorn
> Sent: 24 March 2006 18:37
> To: Tdwg-tag at lists.tdwg.org
> Subject: [Tdwg-tag] RDF instead of xml schema
>
> Hi all,
>
> RDF to me appears on a level of abstraction making it very hard for me to
> follow the documentation and discussion. Most of the examples are embedded
> in
> an artificial intelligence / reasoning use cases that I have no experience
> with.
>
> I am a biologist and I feel comfortable with UML, ER-modeling, xml-schema-
> modeling, and - surprise - relational databases. I believe many others are
> as
> well - how many datastores are actually build upon RDBMS technology?
>
> To me xml-schema maps nicely to both UML-like OO-modeling and Relational
> DBMS.
> I can guess about the advantages of opening this all up and seeing the
world
> as
> a huge set of unstructured statement tupels. But it also scares me.
>
> Angst is a bad advisor. But then if only a minority of the current few
> people
> involved can follow on the RDF abstraction level. A few questions I have:
>
> * Would we be first in line to try rdf for such complex models as
> biodiversity
> informatics?
>
> * Do Genbank/EMBL with their hundreds of employees and programmers use
rdf?
> Internally/externally? The molecular bioinformatics is probably 1000 times
> larger than our biodiversity informatics.
>
> * Why are GML, SVG etc. based on xml schema and not RDFS? Is this just
> historical?
>
> * Are there any tools around that let me import RDF into a relational
> database
> (simple tools for xml-schema-based import/export are almost standard part
of
>
> databases now, or you can use comfortable graphical tools like Altova
> MapForce).
>
> -- I am just trying to test some tools to help me to visualize RDFS
> productions
> (like Roger has send around) on a level comparable with the UML-like
> xml-schema
> editors (Spy, Stylus, Oracle, etc.) I will try Altova SemanticWorks and
> Protege
> over the next week. The screenshot seem to be about AI and semantic web
much
>
> more than about information models (those creatures where you try to
> simplify
> the world to make it manageable...).
>
> Gregor----------------------------------------------------------
> Gregor Hagedorn (G.Hagedorn at bba.de)
> Institute for Plant Virology, Microbiology, and Biosafety
> Federal Research Center for Agriculture and Forestry (BBA)
> Königin-Luise-Str. 19 Tel: +49-30-8304-2220
> 14195 Berlin, Germany Fax: +49-30-8304-2203
>
>
> _______________________________________________
> Tdwg-tag mailing list
> Tdwg-tag at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org
>
>
>
> _______________________________________________
> Tdwg-tag mailing list
> Tdwg-tag at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org
--
Robert A. Morris
Professor of Computer Science
UMASS-Boston
http://www.cs.umb.edu/~ram
phone (+1)617 287 6466
More information about the tdwg-tag
mailing list