March 2006 - tdwg-tag - lists.tdwg.org

TCS in RDF for use in LSIDs and possible generic mechanism.
by Roger Hyam 31 Mar '06

31 Mar '06

Hi Everyone, 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. 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. You can download it here: http://biodiv.hyam.net/schemas/TCS_RDF/tcs_rdf_examples.zip For the impatient you can see a summary of the vocabulary here: http://biodiv.hyam.net/schemas/TCS_RDF/TaxonNames.html and an example xml document here: http://biodiv.hyam.net/schemas/TCS_RDF/instance.xml 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. 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': OWL Ontologies 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. 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 :) Avowed Serializations 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. 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 <http://www.prismstandard.org>group for their standard and it gives a number of benefits as a bridging technology: 1. Publishing applications that are not RDF aware (even simple scripts) can produce regular XML Schema validated XML documents that just happen to also be RDF compliant. 2. Consuming applications can assume that all data is just RDF and not worry about the particular XML Schema used. These are the applications that are likely to have to merge different kinds of data from different suppliers so they benefit most from treating it like RDF. 3. Because it is regular structured XML it can be transformed using XSLT into other document formats such as 'legacy' non-RDF compliant structures - if required. 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. 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. 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. Contents This is what the files in this package are: README.txt = this file TaxonNames.rdfs = An RDF vocabulary that represents TCS TaxonNames object. TaxonNames.html = Documentation from TaxonNames.rdfs - much more readable. instance.xml = an example of an XML document that is RDF compliant use of the vocabulary and XML Schema compliant. avowed.xsd = XML Schema that instance.xml validates against. dc.xsd = XML Schema that is used by avowed.xsd. taxonnames.xsd = XML Schema that is used by avowed.xsd. rdf2html.css = the style formatting for TaxonNames.html rdfs2html.xsl = XSLT style sheet to generate docs from TaxonNames.rdfs tcs_1.01.xsd = the TCS XML Schema for reference. Needs for other Vocabularies 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. Need for conventions 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. The namespaces used in these examples are fantasy as we have not finalized them yet. Minor changes in TCS There are a few points where I have intentionally not followed TCS 1.01 (there are probably others where it is accidental). * basionym is a direct pointer to a TaxonName rather than a NomenclaturalNote. I couldn't see why it was a nomenclatural note in the 1.01 version as it is a simple pointer to a name. * changed name of genus element to genusEpithet property. The contents of the element are not to be used alone and are not a genus name in themselves (uninomial should be used in this case) so genusEpithet is more appropriate - even if it is not common English usage. * Addition of referenceTo property. The vocabulary may be used to mark up an occurrence of a name that is not a publishing of a new name. In these cases the thing being marked up is actually a pointer to another object, either a TaxonName issued by a nomenclator or a TaxonConcept. In these cases we need to have a reference field. Here is an example (assuming namespace) <TaxonName referenceTo="urn:lsid:example.com:myconcepts:1234"><genusEpithet>Bellis</genusEpithet><specificEpithet>perennis</specificEpithet></TaxonName> This could possibly appear in a XHTML document for example. Comments Please 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. What do you think? Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

10 24

A very simple question stated again.
by Roger Hyam 31 Mar '06

31 Mar '06

Hi All, Gregor posted my rather long winded description of confusion about semantics in XML Schema to the list and it may have confused you. It can be summed up with a simple question to which a simple answer is all that suffices. *"Are the semantics encoded in the XML Schema or in the structure of the XML instance documents that validate against that schema? Is it possible to 'understand' an instance document without reference to the schema?"* Possible answers are: 1. *Yes:* you can understand an XML instance document in the absence of a schema it validates against i.e. just from the structure of the elements and the namespaces used. 2. *No*: you require the XML Schema to understand the document. This is not a trivial question. The answers may require different approaches to an overall architecture. Versioning of schemas, for example, becomes irrelevant if the answer is Yes - as the meaning is implicit in the structure you can throw the schema away and not loose anything. XML is 'self describing' so you would think this must be true. The schema is just a useful device to help you construct XML in the correct format. If the answer in No then we need clear statements about how all instances must always bear links to a permanently retrievable schema - or they become meaningless. We need very tight version control of schemas and a method of linking between the versions so we can track how the meaning has changed. We also need clear statements on what happens when you can validate a document with multiple schemas? Does this imply multiple meanings? Schemas must be archived with any data etc. If you respond to this message please state a preference for either 1 or 2. There is no middle road on this one! All the best, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

6 12

Re: [Tdwg-tag] RDF instead of xml schema
by Donald Hobern 30 Mar '06

30 Mar '06

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(a)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(a)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(a)lists.tdwg.org > [mailto:Tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Gregor Hagedorn > Sent: 24 March 2006 18:37 > To: Tdwg-tag(a)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(a)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(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org > > > > _______________________________________________ > Tdwg-tag mailing list > Tdwg-tag(a)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

5 4

Tweaks to LSID tester
by Roderic Page 30 Mar '06

30 Mar '06

Based on feedback from Damian Barnier and Roger Hyam I've tweaked the LSID tester (http://linnaeus.zoology.gla.ac.uk/~rpage/lsid/tester/). The most noticeable change is that the "RDF" display should work on a wider range of LSIDs. Previously it assumed the RDF started with a <rdf:Description> tag, which isn't true for some of the metadata people are serving. Regards Rod ------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page(a)bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com

1 0

TDWG Reference Model
by Javier de la Torre 30 Mar '06

30 Mar '06

Hi, While working with OGC standards I sometimes find things that I like and that I find useful for TDWG. One of the most important documents in OGC is the OGC Reference Model (ORM). Maybe you were aware of it already, but just in case: "The ORM provides the overall conceptual framework for building geospatial processing into distributed systems in an incremental and interoperable manner. The ORM is a living document and is updated periodically as OGC memberships continues to advance geoprocessing interoperability" or "The OGC Reference Model (ORM) provides an architecture framework for the ongoing work of the OGC. Further, the ORM provides a framework for the OGC Technical Baseline. The OGC Technical Baseline consists of the currently approved OpenGIS® Specifications as well as for a number of candidate specifications that are currently in progress. " You can find the document at http://portal.opengeospatial.org/files?artifact_id=3836 I think TDWG - TAG should be in charge of maintaining such a document if you find it interesting. I like it very much because, the first time I approached the OGC community, it helped me to understand what was going on, which standards exist, how the interrelate, etc. Let say that it helps you to get the "overall vision". I don't mean that we should use the same technology or strategy!! I just like the idea of having a document like this whatever technology we create/use (although I like it very much ;) ) Javier.

3 2

roger@tdwg.org
by Gregor Hagedorn 29 Mar '06

29 Mar '06

Hi Roger > TAG list url is here with the archive: > > http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org thanks, I registered. > > I need help to understand rdf. Whereas xml schema has a conceptual mapping to > > database or oo-programming design, rdf seem to have none, I lack anything I can > > relate it too. I still have not seen any software to help me understand what > > you produced. > > > RDF is no more complex than xml schema. The RDFS way of doing things is > far more object orientated than schema. It forces you to have classes > and properties whereas arbitrary XML document structures can be > ambiguous as to whether they are defining objects or properties of > objects so - I don't see your reasoning. I never encountered atomizing every statement into subject-predicate-object in OO design... "to whether they are defining objects or properties of objects so": xml schema is about classes, not objects (instances). Can you give an example what you find confusing in xml schema, I don't see it. Of course you do have the strange animal of mixed content in xml schema, but ignoring this (none of the TDWG standard used it) you have classes and each class has a type. The type can be simple or complex, just like in OO languages. I did already tried the primer but it did not help me, it seemed to talk of use cases rather in Artificial intelligence that are hard for me to follow. > The RDF primer is a good place to start reading: > > http://www.w3.org/TR/rdf-primer/ > > It is less than 100 printed pages so can probably be read in an evening > and understood in several evenings! > > There is a tutorial here: > > http://www.w3schools.com/rdf/default.asp > > and loads of books and things > > The key to understanding it I found was that it is about describing > resources not validating documents. When using XML Schema we are trying > to create a set of rules to validate a document that describes the > resource. We are effectively designing forms. With RDF we are describing > the attributes of the resource that we want to use to describe it. Thus > the two things are not mutually exclusive - which I hoped to demonstrate > with my code. That may be a good pointer to the problems I have. Because I do not think we are describing resources. In my mind we are sharing scientific data. I want the data, not the resources. That should be discussed in common, but I already had 0 time the last three days after starting this reply, and plenty of messages have come in.... ------------- > > 3. Secondarily, on cursory reading I saw that you introduced the term > > "GenusEpithet". This does not exist in the codes and is illogical, see def. > > below obtained by Google: > > > > An epithet (Greek and Latin epitheton; literally meaning 'imposed' ) is a > > descriptive word or lapidary phrase, often metaphoric, that is essentially a > > reduced or condensed appositive. Epithets are sometimes attached to a person's > > name, as what might be described as a glorified nickname. Not every adjective > > is an epithet, even worn clichés. An epithet is linked to its noun by long- > > established usage and some are not otherwise employed. > > en.wikipedia.org/wiki/Epithet > > > You are correct and I agree with you in my post as I said that this is > not normal English usage. > > If I call the property 'genus' or 'genusName' then people would be > tempted to use it when they are describing a TaxonName of rank genus. > This would be wrong as a taxon name of rank genus is a uninomial > (monomial) and the 'uninomial' property should be used. > > The property 'genusEpithet' represents the first particle of a binomial > or trinomial name (which happens to consist of the word used as the > genus name). I am open to suggestions for other names but I guess that > genusEpithet is better than firstParticleOfBinomialTrinomialName. > genusPart? genus...? Incidentally under ICBN there is a weird rule that > this word is not actually the genus. If there were homonymic generic > names (two identical) then the species 'belong' to earlier homonym even > if the author of the species intended them to be in the later homonym. > This makes sense but it took me a long time to get it. To me it is not about English usage, but about logic. English in general uses words in a logical way, so do the Nomenclatural Codes. An "Epithet" can never be the first particle (as you describe), because it means "added to something in front of it". It is like calling the front page a TitleAppendix because it is secondary material to main content. I find simple "Genus" best - stick with the codes, but I see your reasoning. Perhaps someone finds something better than GenusPart or GenusNameParticle (I dont), but I would go for them. I never found the rule weird, by the way, it is perfectly logical given the code considers a "name" the name-string, without the authors and publication details logically required in the case of homonyms. It basically safeguards against unnecessary name changes. EDI booking is all ok. Many thanks! Gregor ---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn(a)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

2 2

TDWG Wiki has moved to wiki.tdwg.org
by Ricardo Scachetti Pereira 29 Mar '06

29 Mar '06

Dear TDWG Wiki users, Today we moved the TDWG Wiki from its previous, temporary location at http://biodiv.hyam.net/twiki/ to its permanent server at http://wiki.tdwg.org/. This change should be seamless to you. All of your registration data including your password were transferred to the new wiki and will continue to work as expected. All bookmarks and references to the old wiki will be gently redirected to the appropriate page on the new server. Many thanks to Roger Hyam who provided hosting and system administration services for the wiki in its temporary location, allowing us to use the wiki for the past 5 months, and to Adrian Rissoné and Chris Sleep from the Natural History Museum and Ciprian Vizitiu from GBIF for their help in setting up the new wiki server. Let me know if you have any problems or questions. Best regards, Ricardo Pereira

1 0

Why should data providers supply search and query services?
by Roger Hyam 28 Mar '06

28 Mar '06

This is a little more of a controversial question that has been suggested: "Why should data providers supply search and query services?" * We have many potential data providers (potentially every collection and institution). * We have many potential data consumers (potentially every researcher with a laptop). * We have a few potential data indexers (GBIF, ORBIS , etc + others to come). The implementation burden should therefore be: * Light for the providers - who's role is to conserve data and physical objects. * Light for the consumer - who's role is to do research not mess with data handling. * Heavy for the indexers - who's core business is making the data accessible. Data providers should give the objects they curate GUIDs. This is important because it stamps their ownership (and responsibility) on that piece of data. They then need to run an LSID service that serves the (meta)data for the objects they own. *There work should stop at this point!* They should not have to implement search and query services. They should not anticipate what people will require by way of data access - that is a separate function. Data consumers should be able to access indexing services that pool information from multiple data providers. They should not have to run federated queries across multiple data providers or have to discover providers as this is complex and difficult (though they may want to browse round data providers like they would browse links on web pages). Once they have retrieved the GUIDs of the objects they are interested in from the indexers they may want to call the data providers for more detailed information. Data indexers should crawl the data exposed by the providers and index them in thematic ways. e.g. provide geographic or taxon focused services. This is a complex job as it involves doing clever, innovative things with data and optimization of searches etc. Currently we are trying to make every data provider support searching and querying when the consumers aren't really interested in querying or searching individual providers - they want to search thematically across providers. If a big data provider wants to provide search and query then they can set themselves up as both a provider and an indexer - which is more or less what everyone is forced to do now - but the functions are separate. Data providers would have to implement a little more than just an LSID resolver services for this to work. They would need to provide a single web service method (URL call) that allowed indexers to get lists of LSIDs they hold that have had their (meta)data modified since a certain date but this would be a relatively simple thing compared with providing arbitrary query facilities. I believe (though I haven't done a thorough analysis of log data ) that this is more or less the situation now. Data providers implement complete DiGIR or BioCASE protocols but are only queried in a limited way by portal engines. Consumers go directly to portals for their data discovery. So why implement full search and query at the data provider nodes of the network (possibly the hardest thing we have to do) when it may not be used? This may be controversial. What do you think? Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

4 6

Re: [Tdwg-tag] RDF instead of xml schema
by "Döring, Markus" 27 Mar '06

27 Mar '06

Donald, as you said there are probably more ways of solving our current problems (btw, did we nail them down anywhere?). And in this context I think we should at least mention the UBIF idea based on xml schema: Inspired by SDD there should be a common base schema for all other tdwg schemas, the "Unified Biosciences Information Framework". It will hold common and simple types. All major biodiv-objects (eg names,taxa,specimen,people,bib-refs) become +/- root level elements in the schema with a referrable GUID. Each object would have an extension slot (xsd:any) to carry any other data defined in extension schemas. Does UBIF miss any of our requirements? The main trouble with UBIF was to agree on THE unified model and force the other standards to adopt it. But that is something we will face in any solution regardless of technology. We will all have to come together to model the core entities at least. By the way, in UBIF the largest part was about dataset metadata (metadata about the information source). How would we share this data in RDF? Would every RDF biodiv-object reference another metadata resource, based on dublin core? Markus -----Ursprüngliche Nachricht----- Von: Tdwg-tag-bounces(a)lists.tdwg.org [mailto:Tdwg-tag-bounces@lists.tdwg.org] Im Auftrag von Donald Hobern Gesendet: Samstag, 25. März 2006 10:18 An: Tdwg-tag(a)lists.tdwg.org Betreff: Re: [Tdwg-tag] RDF instead of xml schema 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(a)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(a)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(a)lists.tdwg.org > [mailto:Tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Gregor Hagedorn > Sent: 24 March 2006 18:37 > To: Tdwg-tag(a)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(a)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(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org > > > > _______________________________________________ > Tdwg-tag mailing list > Tdwg-tag(a)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 _______________________________________________ Tdwg-tag mailing list Tdwg-tag(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag_lists.tdwg.org

3 2

Re: [Tdwg-tag] RDF instead of xml schema
by Gregor Hagedorn 27 Mar '06

27 Mar '06

(Moving this from SDD list to Tdwg-tag list...) Dear Roderic many thanks for your answers. > triples in one table with three columns (subject, predicate, object). I > guess for most people the issue is getting data out of RDBMS into RDF, > not the other way around. SDD and TaxMLit are about building tools for biology to create and share descriptive data, identification keys, online digital taxonomic monographs. These are knowledge documents - intended to replace their printed equivalents. Many people hopefully will produce them and share (or even sell them) under various schemes - hopefully often under open licenses like cc. Building these tools is a huge amount of work. The vision of SDD is not only to share data in a one-way street, but to share the work of applications by having specialized application that read data, do the thing they can best, write them back for the next app that does something else better. Ideally nothing should be lost in this process. I realize that RDF is a good solution for the DiGIR kind of data advertisement, but is it good for data sharing? > Tools > ------- > > As one who positively hates the diagrams XMLSpy produces I'm biased, > but when I played with Altova SemanticWorks I was distinctly > underwhelmed. What can we use then? Is there any UML-tool (static class class diagram would be fine for a start) that automatically produces RDFS? (I still do not understand whether RDFS attempts to cover the syntactical knowledge required for static class diagram - but other posts seem to imply this) Gregor---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn(a)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

3 2