- tdwg-content - lists.tdwg.org

[tdwg-spm] Species profile model instance examples
by Eamonn O Tuama 14 Jun '07

14 Jun '07

Bob has created a page on the Species Profile Model wiki for instance examples (http://wiki.tdwg.org/twiki/bin/view/SPM/InstanceExamples). You are all encouraged to put your own examples there and add comments too. In reaction to the AbiesAlba example and observations from Marcus, I have put up one on SalmoSalar and posed some further questions. Please contribute. Best regards, Éamonn

1 0

[taxon-data-model] Re: taxon data model
by Markus Döring 12 Jun '07

12 Jun '07

Éamonn, I have prepared a simple SpeciesPage example based on the current ontology. http://ww3.bgbm.org/tmp/abiesalba.rdf I hope this helps and also that it's really correct. At least it validates with w3c's validator. You can also view it with the new AJAX based OpenLink RDF browser: http://demo.openlinksw.com/DAV/JS/rdfbrowser/index.html two things struck me when writing this example: - where do I put a PublicationCitation? I would want to cite all sources for every information and I dont know where/how. Is this missing or part of the base/core ontology already? - hasInformation is a bit redundant, but the validator did complain when I declared all InfoItems under a single hasInformation node. Was this intended? I guess yes, cause otherwise the InfoItems would have to be properties. best wishes -- Markus On 28.06.2007, at 13:11, Eamonn O Tuama wrote: > Dear Gregor, > > I do not see it being a case of SDD versus SPM. SPM will only be > needed if > SDD cannot fulfill the use cases of the latter. It would be great > if you > would accept Roger's invitation to act as champion of an interest > group that > covers descriptive data, whether covered by SDD, SPM, whatever. Bob > would be > a good person to talk to because of his knowledge of SDD and his > attendance > at the GBIF SPM workshop where we initiated discussions. > > Question to Marcus: did you manage to develop the SPM instance > examples we > talked about? I think they will help the interest group, particularly > non-modellers, to understand what's involved. > > Best regards, > > Éamonn > > -----Original Message----- > From: Roger Hyam [mailto:rogerhyam@googlemail.com] On Behalf Of > Roger Hyam > Sent: 28 May 2007 12:36 > To: G. Hagedorn > Cc: Eamonn O Tuama; Markus Döring; Lee Belbin > Subject: Re: taxon data model > > > Hi Gregor, > > I had hoped that Bob would have talked to you about this. We spoke to > him very deliberately in Copenhagen before he came to see you about > the overlap with SDD and he said he would discuss it with you. > > There was a consensus at the meeting I believe that there should be > an interest group that covers descriptive data that contained task > groups to do things on SDD, SDD-Lite? TDM (now called SPM I believe) > perhaps images or whatever. That way there would be a forum to deal > with any of these potential overlaps. I was hoping that he would > persuade you to step forward as a champion for such a group! > > Please discuss with Eammon who is championing the SPM and Markus who > is looking at re-modeling what we came up with. I have cc'd them in > on the email. > > All the best, > > Roger > > > > On 22 May 2007, at 17:48, Gregor Hagedorn wrote: > > > >> Hi Roger >> >> I am just responding because of Adrian's call for the TDWG program. >> >> I understand that the Taxon data model redevelops a lot of the >> concepts of SDD >> in a different light. >> >> I do not say what you do is wrong if you are only interested in >> free-form text. >> SDD is about structured data and about mixed situations. But I >> wonder whether >> you really never want to move into more structured forms. >> >> I am worried or just don't see how your future extensibility would >> work. How >> can I learn that? >> >> We did have reasons to consider text characters a form of >> character, but the >> reasons we did it is to have typed characters and free-form text >> mixtures >> supported. In the markup part, you can also markup with any number >> of high- >> level concepts. >> >> I would really like to have discussions on this, on what you >> learned, and that >> would include possibly changing SDD into something new. I hope both >> sides could >> learn. >> >> What can you suggest? Should we have a session on SDD versus TDM at >> TDWG? >> >> Would you be willing to talk on the descriptive data part? Do you >> suggest other >> talks? >> >> I appreciate your help if you can! >> >> 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 1

Re: [taxon-model] Re: Owl polymorphism
by Markus Döring 11 Jun '07

11 Jun '07

Im not sure why we are talking about inheritance. My primary goal is to see how useful TDM is for data exchange and integration. I am very interested for example to use TDM to exchange species distribution data. If every application defines its own occurence status terminology noone would be able to merge datasets. So I was hoping TDWG would at least define a default standard for those kind of things. I am aware that some communities will use a different standard, but if they want to be interoperable with the outside world how can you see this happen if we dont define a common terminology? Reason over hundreds of SameAs statements? It would be nice to have at least a standard "backbone" where you can relate your terminology against. And if we agree that this is needed, why not have a strongly typed property for the respective InfoItem classes that only allows terms of the recommended terminology? But maybe I misinterpreted the purpose of TDM and/or are still too heavily influenced by xml schema ;) cheers -- Markus On 11.05.2007, at 13:56, Bob Morris wrote: > Alas, for some of the intended audiences, there are requirements of > practice, or even of law, to use particular controlled vocabularies. > Often, there are several in wide use. This is especially true in the > invasive species community, but also, I believe, for many > agriculture, public health and other communities. > > My inclination is to share Roger's concern about an inheritance tree > adding complexity that might add to the complexity of either > application building or adoption. (I can't believe I'm agreeing with > Roger in this domain... :-) ). Unfortunately, my intuition is that > two related problems will quickly arise: > > (a). The inexperience, and a small stake in the outcome, of the > various communities will quickly lead to an undisciplined inheritance > tree in which most people derive from the base, not from other > derivations. This in turn makes effective and easily extended > polymorphic application programming difficult or impossible to put in > place. If the utility of polymorphic programming is compromised, > there seems small point accepting the maintenance hit of polymorphic > ontology. It's a little like the difference between tags and property > lists. You can go an awfully long way with the former even though they > just float by like clouds. > > (b)For similar reasons to (a), even when disciplined extension > lineages emerge, there will be rooted at them further undisciplined > derivations as above, and that these will lead to \semantic/ > multipaths through the inheritance trees as people map undisciplined > leaf nodes in one branch to those in another. > > For a number of the TDMTerm categories there are already multiple well > established controlled vocabularies. Many of the relevant > subcommunities are communities of practice, not of theory, and feel > more constrained to "get on with it" about their work than to make > sure it is easily related to the vocabularies of other subcommunities > much less apparently unrelated communities. I believe this is > especially true where ecology, public policy, commercial or health > data are in play. It is a little regrettable that the list and wiki > name got abbreviated from Taxon Data Model to Taxon Model. The latter > might give taxonomists the mistaken (I hope) view that TDM is about a > theory of what a Taxon is. > > > > > On 5/11/07, Markus Döring <m.doering(a)bgbm.org> wrote: >> Roger, >> this was not targeted directly at TDM. I was mainly exploring OWL and >> definitely not suggesting multiple inheritance! >> >> But in regards to TDM I was thinking about the consequences of >> allowing any defined term as a "controlled" value for >> InfoItems.hasValue. Is this desired? Having individual classes for >> the InfoItem categories now would allow us to define a specific >> controlled vocabulary for each category - or None if we dont think >> this is a good idea. These vocabularies, like CyclicityTerm, can >> easily be extended by anyone who really needs to. And all InfoItems >> are allowed to contain uncontrolled values via the hasContent >> property in any case. >> -- >> Markus >> >> >> >> On 11.05.2007, at 11:30, Roger Hyam wrote: >> >> > >> > Hi Markus, >> > >> > Sounds like interesting and complex stuff and exactly what I am >> > trying to avoid ;) >> > >> > If this is for exchange standards we want to keep things as simple >> > as possible. We also need our ontology to entail as little as >> > possible so people can understand it and (if they are up on the >> > technology) import it into their own business ontologies. >> > >> > The role of the exchange ontology is to denote the meaning of >> > simple fields it is not to enable connotations but to avoid them. >> > >> > This is why I was sticking to simple properties with domains and >> > ranges. Really just one up from RDFS. If it is important for a >> > consumer to assert a hierarchy of properties then they can do that >> > in their own ontology and import it. Who is to say that all >> > consumers will have the same notion of that hierarchy and what is >> > the business case for trying to impose one at this point? >> > >> > If there were polymorphism of properties (overriding them in sub >> > classes) then it would get confusing because of the multiple >> > inheritance. I am not sure what would happen to meaning with the >> > diamond problem - where the same property is inherited via several >> > routes but has it's meaning changed differently on each route. It >> > is always possible to subclass the property though and it may be >> > possible to forbid the use of the parent property in a class - >> > perhaps - but this is getting beyond my reading level. >> > >> > Not sure if this helps, >> > >> > All the best, >> > >> > Roger >> > >> > >> > >> > >> > On 11 May 2007, at 09:54, Markus Döring wrote: >> > >> >> Roger, >> >> is it possible with OWL to have polymorph class properties? >> >> As properties are global and only bound to classes via range/ >> >> domain it doesnt seem to be possible to me, but maybe Im wrong. >> >> Can I redefine a propertys range depending upon the class it >> >> belongs to, so its domain? Well, that would mean to declare the >> >> same property twice with different domains and ranges. Probably >> >> impossible. It is different from classic OO thinking... >> >> -- >> >> Markus >> >> >> >> >> >> >> > >> >> _______________________________________________ >> taxon-model mailing list >> taxon-model(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/taxon-model >>

4 3

[tdwg-tnc] Species profile model group meeting at TDWG 2007 Conference
by Eamonn O Tuama 08 Jun '07

08 Jun '07

Dear TDWG TNC Member, We plan to hold a group discussion about the "Species Profile Model" SPM (previously known as "Taxon Data Model") at the TDWG 2007 conference, possibly on Sunday 16th during the group meetings slot (09.00-17.00). We are trying to gauge interest and potential numbers and to avoid clashes with other parallel discussions that might be taking place. The SPM is intended to describe species facts (organised into categories) as might appear in "species bank" type web applications like Encyclopedia of Life or FishBase/SeaLifePortal. We do not intend to duplicate the work of TCS and SDD for nomenclature and taxonomy but rather draw on them, and other TDWG standards, wherever appropriate. We want it to fit in with the TDWG technical architecture and will work closely with all concerned to do this. It seemed to us that the SPM was sufficiently distinct to warrant set up a new group within TDWG with cross linkages to other groups where appropriate. For a background, see the wiki here: http://wiki.tdwg.org/TaxonDataModel, and the summary of a recent workshop held at GBIF here: http://wiki.tdwg.org/twiki/bin/view/TaxonDataModel/SpeciesModelWorkshopRepor t. You can subscribe to the taxon-data-model mailing list here to follow developments and contribute: http://lists.tdwg.org/mailman/listinfo/taxon-data-model (mailing list information web page) taxon-data-model(a)lists.tdwg.org <mailto:taxon-data-model@lists.tdwg.org> (mailing list web address) Please reply to me directly to let me know if you are interested in attending the SPM workgroup during the TDWG conference. At this stage it is purely to get a rough indication of numbers so there is no real commitment required on your part. Best regards, Éamonn ________________________________________________________________ Éamonn Ó Tuama, Ph.D. (eotuama(a)gbif.org), Senior Programme Officer for Data Access & Database Interoperability (DADI), Global Biodiversity Information Facility Secretariat, Universitetsparken 15, DK-2100 Copenhagen Ø, DENMARK Phone: +45 3532 1494; Fax: +45 3532 1480

2 3

[tdwg-ncd] RE: NCD status summary
by Neil Thomson 05 Jun '07

05 Jun '07

Hi Markus, Sorry for the delay in responding to this. I have interspersed comments below and Cc:'d in the RAVNS since there are some changes here that are potential workshop agenda items. Thanks for your help with this ... -----Original Message----- From: Markus Döring [mailto:m.doering@BGBM.org] Sent: 01 June 2007 14:51 To: Neil Thomson Cc: Ruud Altenburg Subject: NCD status summary Neil, I have been working on the schema and the ontology lately. They don't match a 100%. In my opinion it would be best to focus on one specification only instead of trying to maintain and keep in sync 2 specifications for different target platforms (XML+RDF). If we need to do that, I strongly suggest to do the real modelling in an abstract form with UML and derive a schema and ontology from that! You can also create a suitable database schema from UML automatically if you want. Im not sure how to go about this decision. Maybe its best to discuss this during the workshop? ## NT: We should complete the schema v1.0 at least before transferring to another technology. Maybe you could cover the reasons for moving and how it will affect future developments in your session at the workshop? ----------------------- In regard to the php toolkit I think this decision doesnt have a very strong impact as long as the toolkit doesn't implement im/export via xml or rdf yet. I suggest to work with the schema for now cause this is 99% complete. On the other hand I believe the RDF version is the preferred tdwg format, so we should use this ontology as the reference. And as I said its not exactly the same as the ncd schema, as it is part of the tdwg ontology and uses external ontologies too (like vcard). ## NT: ok, that's good in that it should not hold Ruud up too much. --------- Detailed issues that still need to be resolved are: *** SCHEMA *** - what IDs should exist? 1 NCD guid (lsid or whatever) + many others with source. Is this correct? ##NT: Only the NCDID needs to be generated, probably as an LSID. All other identifiers are taken from elsewhere (i.e.the "source") ------------------ - are multiple parent collections & parent institutions allowed? currently this is not ##NT: Yes, they should be allowed ------------------ - person roles not fixed or at least core suggested? I think we need this ##NT: Yes, we do need this ------------------ - what is "richRecordSearchString" in contrast to "collectionDatabaseURL"? what about "objectAccessService" and simply "furtherInformation" ? ##NT: The "collectionDatabaseURL" is the URL of the database that holds item-level data for the collection being described in this NCD record. The "richRecordSearchString" is what should be used in that database to get directly to the relevant record. To take an example, there will be an NCD record describing a herbarium. The "collectionDatabaseURL" will be to the Index Herbariorum WebDatabase and the "richRecordSearchString" will contain the coden for the herbarium so that the full description of the herbarium can be found by adding the two together. I have no objection to "objectAccessService" for the latter, but the former is more explicit than "furtherInformation". ------------------- - I have replaced all address information with vcard elements. That is vc:N for person names and vc:ADR for addresses. Some existing NCD elements do not exist in vcard though. How shall we treat them? Right now Ive simply left them as they were before in addition the vcard elements. It looks a bit weird, but its ok I believe. In particular that is byear and deathyear for persons (full birthday exists in vcard) and fax, email, logourl for institutional addresses. Maybe we can remove the email and fax and add a website instead? The collection have real contacts anyway already, so institutions dont really need this, do they? ##NT: Yes, institutions do require contact details too so I would prefer that these elements remain. If they are not present as vc: elements then can they just be ncd: elements? ------------------- - many elements cover the same ideas that dublin core covers. Should we use the explicit dublin core elements for title, description, other resources, keyword, rights, modified, created and citation? I would be in favor to do so. It would mean that NCD mainly is about the extra metadata bits that dublin core doesn't cover! ##NT: We certainly could do this and Doug has produced an NCD <--> DC mapping. Since this would just be a re-labelling exercise we can have this as a discussion item at the workshop. NCD would then be an application profile, re-using elements from mets:, dc: and vc: along with its own. ------------------- *** ONTOLOGY *** - collection extent is a pure integer without a unit definition. I know this is bad, but having complex data (i.e. with multiple elements or attributes) in an ontology means I would have to define a new class just for this. And Roger is very keen on keeping the number of classes low. ##NT: In this case the single attribute should be a string not an integer. Describing a collection extent as "2" is spectacularly meaningless. If the string is "2 shelves" or "2 cupboards" or "2 rooms" it means a little bit more. Not much, but enough for someone to assess whether it is worth a visit or not. -------------------- - all keywords lacking strength flag cause I have created a single keyword class that is used by all keyword types. And the strewngth flag didnt exist for all keywords. Should it or should we drop it? ##NT: I would like to keep the strength flag if possible fot those elements where it makes sense - it would be good to indicate where the collection owner believe's the collection to be particularly strong. -------------------- - a persons role in regard to a specific collection is missing. I think we need it, but then again we need at least a basic controlled vocabulary ##NT: Yesm we do need this. Example terms would be owner, adminstrator, collector, preparator etc. ------------------- I think thats all there is. It looks like a lot, but most issues are of a cosmetic nature and do not change the abstract standard. Some like multiple parents do of cause. I would be glad if you could reply to these questions as soon as possible, even if its only partly, cause I hope to find some time over the weekend to settle some of them. ##NT: Thanks again for looking at these details. It was always known that changes would be needed for the toolkit to work and others may well come to light during testing. We can also talk that through at the workshop, since I think that some of the RAVNS are keen to help with the testing. Is everyone in agreement with the changes proposed above? We need to quickly move to v1.0 so that Ruud can strut his stuff. Apologies again for the unintended out-time recently. All best wishes, Neil ----------- best wishes -- Markus http://rs.tdwg.org/ontology/voc/ http://rs.tdwg.org/ncd/dev/schema/ncd.xsd

3 4

[Biogeosdi] RE: [tdwg-tapir] Executive summary available
by Meganck Bart 05 Jun '07

05 Jun '07

Hi Tim, hi Renato, The link to our demo website http://omtest.cria.org.br/biogeosdi/ seems to be working slowly or not at all... ? This is a pity, because what we did in Campinas was really relevant to the other projects we're working on, and I often refer to our demo implementation to demonstrate how standard-compliant existing services can be strung together in a user-friendly way. I'll be referring to it next Tuesday on the DeeGree user's day in Bonn (which is nice, given the fact that we didn't even use DeeGree as WMS - but OGC is OGC, no ? ;-) and the 18th in the bioinformatics block of the 7th Flora Malesiana symposium 2007, Leiden. Could you see if the server is still fully functional ? best regards - I often miss the coconuts... Bart. ########################################### This message has been scanned by ICT - Africa Museum ________________________________________ 5/6/2007 - Filtered through antispam by ICT

2 2

[taxon-model] Taxon Data Model list now operational
by Eamonn O Tuama 25 May '07

25 May '07

The Taxon Data Model list is now operational. To maintain continuity, I have copied the relevant emails of the past week into an "archive" below. Please use this list from now on to continue the discussions. Best regards, Éamonn -----Discussion on TDM that took place between 2 and 7 May 2007 ----- ------------------- from Renato -------------------------------------------------------- OK, so I "think" I'm starting to understand the problem that has led to the current approach taken by the taxon data model. Trying to make a quite simplified analogy with specimen data, imagine a collection that used a simple OCR process in all labels and now it has only one table with a single textual field. Since we can find different things in labels (some may have coordinates, others not, some may have collecting date, etc.) the suggestion for this kind situation would then be to tag all records individually. For instance saying that "in this specific record you may find something about the location, in this other record you may find something about location and date" and so on. Now back to species databases, if tagging is really something at the record level (and I suppose it is), I would be really surprised to see a species database which is ready to use some kind of tagging mechanism. Tagging at the record level would therefore require changing the data structure and revising all records. If this kind of work is being considered, then why not restructure everything according to the new terminology that was proposed during the meeting? Unless we are talking about some kind of data that simply cannot be separated and structured according to the proposed terms... Looking at the results of the meeting, it's really tempting to take all terms and put them into a simple conceptual schema like DarwinCore. It would not only provide a common XML vocabulary, but we would almost instantly benefit from the existing technology for sharing/accessing distributed data. >>>From the TAPIR perspective, data exchange schemas like PlinianCore could be seen as output models. All providers from the different networks could still try to map the same agreed terms/concepts. If tagging will not take place at the record level, but at the field level, like "I have field X which sometimes has content about behaviour, sometimes about evolution, sometimes both, so I will automatically tag all records with both terms", then I see no big difference if in the current way of using TAPIR we just take the two corresponding concepts and map them against the same local field. RDF could still be one of the TAPIR outputs, but the ontology would probably need a different approach (as discussed in previous messages). Best Regards, -- Renato ------------------- from William ------------------------------------------------------- Hi Renato, Bob and all, I am a new to this thread and I have not been able to go through it all, but as some of you already know, for the IABIN Species and Specimens Thematic Network we will be setting up TAPIR providers with information on Species structured with the Plinian Core (www.pliniancore.org). The first providers will hopefully be ready by mid-year... our datasource (~4K Species records), will hopefully be on-line in the next month... Additionally, I would really like to try coding some of the information from our Timber Tree Species from the Flora of Costa Rica to set up the TDM on top of that, particularly looking for those that do not map well. I promise to write back next week, William Ulate Coordinator Biodiversity Informatics Unit Instituto Nacional de Biodiversidad, INBio. P.S.: Where can I find the minutes/results of the Workshop? ------------------- from Bob ------------------------------------------------------------ Renato De Giovanni wrote: > > > Anyway, I'm not quite familiar with species-level data sources. From > the previous messages, it seems that the main reason for using the > generic tagging approach is that most data sources will have chunks of > text including information about one or more TDM categories, and it > will be impractical to separate this information in a more structured > way. Did I understand the problem correctly? Yes, but it is worse. Many such sources have \both/ textual---but categorized---data and structured data. And both may need ontological mapping so that both machine integration and human display applications have a chance of putting together the right stuff and also not ignoring what the client wishes not be ignored. > > In this case, then you're right that it would be interesting if > someone could investigate this a bit more, make some tests and give us > a more practical feedback. If most participants of the species model > workshop have this kind of database, maybe they could try to map their > fields to the TDM categories. I am presently doing some of that, albeit first trying to hand code some instances with Protege and Altova SemanticWorks. I guess the interesting part will come for stuff that \doesn't/ map well. At the moment, I am somewhat at a loss for what our intent was in this case, but maybe in another few hours I will have figured that out. ... Bob ------------------- from Renato ----------------------------------------------------- Hello Roger, Markus was right on his comment. I wasn't thinking about any particular implementation of TAPIR, I just wanted to warn about some implications of using generic models like TDM in the TAPIR context. Take DarwinCore as an example: * Most providers of specimen data use relational databases where Darwin concepts correspond to table columns, so the mapping process is easier. * If I'm a client and I'm interested in providers that have content for lat/long, I can just inspect the capabilities response to see if they mapped the corresponding concepts. * Since we have different concept ids for each kind of data, we have more possibilites when designing output models. Now if I understood correctly, TDM is so generic that the same kind of model could be used for DarwinCore - just replace the TDM terms by the Darwin concepts. And although there's nothing intrinsically wrong with this approach: * If most providers will have databases where TDM categories correspond to table columns, then they will need to prepare a super view to make all data appear under a single InfoItem column, just beside another column with the corresponding category value. It's possible, but it's more work for providers and performance will not be good. * If I'm a client and I'm interested in providers that have content for habitat, I cannot simply inspect the capabilities response, because it will just show me that the providers have InfoItems. I'll need to send additional search/inventory requests to discover what kind of data is available. * Since there will be only a few generic concepts, output models will be very limited in TAPIR. As you know, at the moment we cannot have conditional mappings in TAPIR, for instance: InfoItem corresponds to element habitat only when category equals habitat. I'm not against generic models. I also used them myself in specific circumstances like meta modelling applications, or when the application had such a mutable nature that it was better to use a more generic approach (even at the cost of performance penalties and other additional work). Anyway, I'm not quite familiar with species-level data sources. From the previous messages, it seems that the main reason for using the generic tagging approach is that most data sources will have chunks of text including information about one or more TDM categories, and it will be impractical to separate this information in a more structured way. Did I understand the problem correctly? In this case, then you're right that it would be interesting if someone could investigate this a bit more, make some tests and give us a more practical feedback. If most participants of the species model workshop have this kind of database, maybe they could try to map their fields to the TDM categories. Best Regards, -- Renato ------------------- from Marcus ------------------------------------------------------- Hello, some small corrections below regarding my understanding -- Markus On 04.05.2007, at 12:58, Roger Hyam wrote: > Hi Markus, > > I am replying to this and cc'ing the TAG list because I really think > we should be having the discussion there. I am sure there are other > people who might like to be involve from a technical stand point. I > hope they can read this message thread backwards to catch up. > > If I can summarize: > > We are talking about the data models that were dreamt up at the > SpeciesDataModel workshop > > http://rs.tdwg.org/ontology/voc/TaxonDataModel > http://rs.tdwg.org/ontology/voc/TDMTerm > > The choice is whether to have an inherited hierarchy of classes of > object to represent information items or to have a single information > item and 'tag' it with categories (instances). The inherited hierarchy of classes is not needed for semantics in both approaches. We can derive *all* classes directly form the base InfoItem class. Just as you are planning to do with the controlled vocabulary terms, deriving them from BaseTerm. This kind of inheritance is more technical by nature simply passing on all properties of InfoItems. The semantical hierarchy InfoItem- >BehaviorInfoItem->EvolutionaryBehaviorInfoItem can be modelled in both approaches if we want. But in both ways we dont have to! > Having info items as different classes means that they would be > possibly be clearer in a straight serialization. > > <tdm:TaxonDataModel> > <tdm:aboutTaxon>.....</tdm:aboutTaxon> > <tdm:hasInformation> > <tdmt:Behaviour> > <tdmt:hasContent>Some stuff about behaviour</tdmt:hasContent> > </tdmt:Behaviour> > </tdm:hasInformation> > <tdm:hasInformation> > <tdmt:Evolution> > <tdmt:hasContent>Some stuff about evolution</tdmt:hasContent> > </tdmt:Evolutionr> > </tdm:hasInformation> > <tdm:hasInformation> > <tdmt:BehaviouralEvolution> > <tdmt:hasContent>Some stuff about evolution of behaviour</ > tdmt:hasContent> > </tdmt:BehaviouralEvolution> > </tdm:hasInformation> > </tdm:TaxonDataModel> > > But taking the tagging approach: > > <tdm:TaxonDataModel> > <tdm:aboutTaxon>.....</tdm:aboutTaxon> > <tdm:hasInformation> > <tdm:InfoItem> > <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Behaviour"/> > <tdmt:hasContent>Some stuff about behaviour</tdmt:hasContent> > </tdm:InfoItem> > </tdm:hasInformation> > <tdm:hasInformation> > <tdm:InfoItem> > <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Evolution"/> > <tdmt:hasContent>Some stuff about evolution</tdmt:hasContent> > </tdm:InfoItem> > </tdm:hasInformation> > <tdm:hasInformation> > <tdm:InfoItem> > <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Behaviour"/> > <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Evolution"/> > <tdmt:hasContent>Some stuff about evolution of behaviour</ > tdmt:hasContent> > </tdm:InfoItem> > </tdm:hasInformation> > </tdm:TaxonDataModel> > > Renato raised questions about serving that tagged version with TAPIR > by which I think he meant TAPIRLink as it would not be possible to do > the above example as a flat schema. This is the same problem as > serving multiple identifications for a specimen I guess > - is this right? Not really. I think the problem has to do with creating an XML schema to be used for a TAPIR model that has *different* node paths to be mapped to. Using the generic InfoItem "metamodel" you always end up with this path that you map to: /tdm:TaxonDataModel/tdm:hasInformation/tdm:InfoItem/tdmt:hasContent instead of having different ones when using inheritance: /tdm:TaxonDataModel/tdm:hasInformation/tdm:InfoItem/tdmt:Behaviour /tdm:TaxonDataModel/tdm:hasInformation/tdm:InfoItem/tdmt:Evolution /tdm:TaxonDataModel/tdm:hasInformation/tdm:InfoItem/ tdmt:BehaviouralEvolution > Reminds me of the point I think Markus raised it at the beginning. > Why not have InfoItem as the top level element and move the taxon > into it? > > <InfoItem> > <aboutTaxon>...</aboutTaxon> > <category rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Evolution"/> > <hasContent>Some stuff about evolution</hasContent> > </InfoItem> > > Info item is then like a DwC record and the category property is > like the BasisOfRecord. (TAPIRLink couldn't do multiple category > stuff). > > The argument against this is that the metadata would have to be > repeated for multiple InfoItems. Most requests would be for > multiple InfoItems about the same species - I guess but I really > need clearer examples as to what this will be applied to. Who is > going to implement this in the near future? Perhaps they should > have a go and decide? Isn't Wouter doing something on it? I don't > have the time just now to try out some examples and I think that is > what is needed. > > What does everyone else think? > > All the best, > > Roger > ------------------- from Roger --------------------------------------------------------- Hi Markus, I am replying to this and cc'ing the TAG list because I really think we should be having the discussion there. I am sure there are other people who might like to be involve from a technical stand point. I hope they can read this message thread backwards to catch up. If I can summarize: We are talking about the data models that were dreamt up at the SpeciesDataModel workshop http://rs.tdwg.org/ontology/voc/TaxonDataModel http://rs.tdwg.org/ontology/voc/TDMTerm The choice is whether to have an inherited hierarchy of classes of object to represent information items or to have a single information item and 'tag' it with categories (instances). Having info items as different classes means that they would be possibly be clearer in a straight serialization. <tdm:TaxonDataModel> <tdm:aboutTaxon>.....</tdm:aboutTaxon> <tdm:hasInformation> <tdmt:Behaviour> <tdmt:hasContent>Some stuff about behaviour</tdmt:hasContent> </tdmt:Behaviour> </tdm:hasInformation> <tdm:hasInformation> <tdmt:Evolution> <tdmt:hasContent>Some stuff about evolution</tdmt:hasContent> </tdmt:Evolutionr> </tdm:hasInformation> <tdm:hasInformation> <tdmt:BehaviouralEvolution> <tdmt:hasContent>Some stuff about evolution of behaviour</ tdmt:hasContent> </tdmt:BehaviouralEvolution> </tdm:hasInformation> </tdm:TaxonDataModel> But taking the tagging approach: <tdm:TaxonDataModel> <tdm:aboutTaxon>.....</tdm:aboutTaxon> <tdm:hasInformation> <tdm:InfoItem> <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Behaviour"/> <tdmt:hasContent>Some stuff about behaviour</tdmt:hasContent> </tdm:InfoItem> </tdm:hasInformation> <tdm:hasInformation> <tdm:InfoItem> <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Evolution"/> <tdmt:hasContent>Some stuff about evolution</tdmt:hasContent> </tdm:InfoItem> </tdm:hasInformation> <tdm:hasInformation> <tdm:InfoItem> <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Behaviour"/> <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Evolution"/> <tdmt:hasContent>Some stuff about evolution of behaviour</ tdmt:hasContent> </tdm:InfoItem> </tdm:hasInformation> </tdm:TaxonDataModel> Renato raised questions about serving that tagged version with TAPIR by which I think he meant TAPIRLink as it would not be possible to do the above example as a flat schema. This is the same problem as serving multiple identifications for a specimen I guess - is this right? Reminds me of the point I think Markus raised it at the beginning. Why not have InfoItem as the top level element and move the taxon into it? <InfoItem> <aboutTaxon>...</aboutTaxon> <category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Evolution"/> <hasContent>Some stuff about evolution</hasContent> </InfoItem> Info item is then like a DwC record and the category property is like the BasisOfRecord. (TAPIRLink couldn't do multiple category stuff). The argument against this is that the metadata would have to be repeated for multiple InfoItems. Most requests would be for multiple InfoItems about the same species - I guess but I really need clearer examples as to what this will be applied to. Who is going to implement this in the near future? Perhaps they should have a go and decide? Isn't Wouter doing something on it? I don't have the time just now to try out some examples and I think that is what is needed. What does everyone else think? All the best, Roger ------------------- from Marcus ------------------------------------------------------- On 03.05.2007, at 11:18, Roger Hyam wrote: > Hi Markus, > > I have downsized the cc list for this discussion as I think it may be > just confusing to the less technically focussed or otherwise involved > people who would rather just hear the answer. > > I am not sure I totally follow you. Currently InfoItem.category > property has a range of DefinedTerm which means anything that it > should contain an instance of DefinedTerm - i.e. the simplified > controlled vocabulary things we are using. It should perhaps have a > range of http://rs.tdwg.org/ontology/voc/TDMTerm#TDMTerm. yes, so the definition of what the infoitem is about is a separate ontology, thats what I naively called "domain" ontology before. This can be a simple list of terms or a hierarchical list. I suspect you aim at the flat list to avoid inheritance for reasons given in the TAG wiki. > Are you suggesting that we have different InfoItem child classes one > for each of the categories we are talking about (as listed here > http://rs.tdwg.org/ontology/voc/TDMTerm)? > > So we would have > > <owl:Class rdf:ID="EvolutionInfoItem"> > <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/ > Base#InfoItem"/> > </owl:Class> > > and > > <owl:Class rdf:ID="BehaviourInfoItem"> > <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/ > Base#InfoItem"/> > </owl:Class> > > etc. yes. As Renato has mentioned in a related parallel discussion this also allows us to create TAPIR models, cause an XML schema for these classes would have different element names and thus become mappable easily. > > And that instance data would look like this: > > <bii:BehaviourInfoItem> > <ii:hasContent>Some stuff about behaviour</ii:hasContent> > </bii:Behaviour> yes, thats what I was thinking of > If you had evolutionary-behaviour data you might do this > > <bii:BehaviourInfoItem rdf:about="1233"> > <rdf:type rdf:resource="http://rs.tdwg.org/ontology/voc/ > EvolutionInfoItem#EvolutionInfoItem"/> > <ii:hasContent>Some stuff about evolution of behaviour</ > ii:hasContent> </bii:Behaviour> I dont understand your intention here. If you want a more specific infoitem about evolutionary-behaviour why not define a new class? <eii:EvolutionInfoItem rdf:about="1233"> <ii:hasContent>Some stuff about evolution of behaviour</ii:hasContent> </eii:EvolutionInfoItem > > Here we say that the thing 1233 is an instance of both classes. > > The same instance data the way we came up with it at the meeting would > look like this: > > <tdm:InfoItem> > <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Evolution"/> > <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Behaviour"/> > <tdm:hasContent>Some stuff about evolution of behaviour</ > tdm:hasContent> </tdm:InfoItem> alright, so one idea about having a category property is that it allows you to "tag" one fact (infoitem) with several categories. Is that a requirement you had in mind when designing TDM? > The attraction of doing it this way to me (and I think Donald > suggested it) was that it is easy to write a client that will digest > InfoItems without knowing what they are. If the client hadn't heard of > Behaviour it could do nothing with a class based examples unless it > was capable of exploring the class hierarchy and finding something it > did know about and even then there may have been restrictions on the > properties that it didn't understand. > Effectively every client would need to know OWL. well, not really. If all InfoItem instances are bundled through the TDMClass, you know all of the instances in there are InfoItems. And I cant see a difference for an ignorant application in not understanding the class name or not understanding the category class. For OWL aware applications on the other hand this gives extra knowledge which is not as easy to get if you have to understand the categories "domain ontology" / controlled vocabulary (Because you would need to know OWL AND know how to interpret the non-OWL category property) > If an application (particular thematic network) really did want a > BehaviourInfoItem class it could define one itself. > > <owl:Class rdf:ID="BehaviourInfoItem"> > <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/ > Base#InfoItem"/> > <owl:equivalentClass> > <owl:Restriction> > <owl:onProperty rdf:resource="tdm:category" /> > <owl:hasValue rdf:resource="http://rs.tdwg.org/ontology/voc/ > TDMTerm#Behaviour" /> > </owl:Restriction> > </owl:equivalentClass> > </owl:Class> > > Which I believe would give the same inferences that would be found by > going with subclasses (though I am no expert). > > The important thing is that we keep the instance data as simple and > stable as possible and impose meaning later. > > If we were working in a pure semantic web world I would be more > inclined to go down the class based route but we have to also deal > with instance data as if it were plain XML documents that we can use > through TAPIR, validate with XML Schema and transform with XSLT. exactly this will be a problem if everything is an InfoItem... > We could always change the definitions of the tdm:hasValue property > (and the others) so that they inherit from a high level property. > This kind of change is good because it doesn't affect the instance > data. > > Have I understood your points correctly or have I just gone off on a > circle explaining something that is completely off track? I think we are one the same track. Thanks for the insight, Roger! Markus ------------------- from Bob ------------------------------------------------------------ On 5/3/07, Roger Hyam <roger(a)hyam.net> wrote: Hi Markus, [...] The same instance data the way we came up with it at the meeting would look like this: <tdm:InfoItem> <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Evolution"/> <tdm:category rdf:resource=" http://rs.tdwg.org/ontology/voc/ TDMTerm#Behaviour"/> <tdm:hasContent>Some stuff about evolution of behaviour</ tdm:hasContent> </tdm:InfoItem> The attraction of doing it this way to me (and I think Donald suggested it) was that it is easy to write a client that will digest InfoItems without knowing what they are. If the client hadn't heard of Behaviour it could do nothing with a class based examples unless it was capable of exploring the class hierarchy and finding something it did know about and even then there may have been restrictions on the properties that it didn't understand. Effectively every client would need to know OWL. <naive> Ability to cleanly ignore stuff is very important to me as an application writer. I don't yet have a clear vision of what this means for the current discussion. I might later this week or next, because one of the too many things I am doing at the moment is trying to hand-code some TDM instances from some of the species data that we have in UMB Electronic Field Guide (EFG) data. This is more an exercise in learning the tools (Protege and Altova SemanticWorks) than anything else, but it has given me an appreciation of the simultaneous advantage and pain of being able to ignore classes, or not, with OWL. My experience is very possibly due to naive, learning-effect use of the tools so may not be worth much. It arises from my initial annoyance with Protege for not recursively importing what seemed to me to be the most central TDWG ontologies that TDM itself references directly or indirectly, notably TDMTerm and TaxonConcept. [I don't yet know what Altova does about this]. My annoyance began to turn to gratitude when--with more and more stuff in TDM that happens to not be represented in EFG data--I became relieved about the more and more stuff that \wasn't/ in my face when I would never use it. [The instance management tools ought themselves to be semantically aware. I should be able to tell Protege---or better, it should learn---what I care about...] </naive> If an application (particular thematic network) really did want a BehaviourInfoItem class it could define one itself. <owl:Class rdf:ID="BehaviourInfoItem"> <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/ Base#InfoItem"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="tdm:category" /> <owl:hasValue rdf:resource=" http://rs.tdwg.org/ontology/voc/ TDMTerm#Behaviour" /> </owl:Restriction> </owl:equivalentClass> </owl:Class> Yes, but... this will not solve the problem of proliferation of concepts and the need to relate them to one another when applications \don't/ want to ignore them. The only maxim that the open world assumption addresses is "ignorance is bliss". It leaves you on your own to deal with "a little bit of knowledge is a dangerous thing." "A little learning is a dangerous thing; drink deep, or taste not the Pierian spring: there shallow draughts intoxicate the brain, and drinking largely sobers us again." Alexander Pope (1688 - 1744) in An Essay on Criticism, 1709. First use of the maxim, according to phrase.com "Yet ah! why should they know their fate? Since sorrow never comes too late, And happiness too swiftly flies. Thought would destroy their paradise. No more; where ignorance is bliss, 'Tis folly to be wise" Thomas Gray Ode on a Distant Prospect of Eton College, 1742 I propose these two poems as the TDWG standard for the poetic representation of RDF. :-) Which I believe would give the same inferences that would be found by going with subclasses (though I am no expert). Nor I, but this smells like a place where application writers would find themselves staring into the fiery pit of OWL Full. Remember that classes cannot be instances in OWL DL, i.e. there is no Class class. This is very annoying in OOP and makes code-reuse harder. If reasoning with subclasses turns out to require a Class class, then modeling TDM that way removes it from first order logic. The important thing is that we keep the instance data as simple and stable as possible and impose meaning later. As we know, "instance data is simple" to biologists means "instance data is a row in a spreadsheet". Hah, hah, just serious. Further, close to the only cell entry tolerable is text, a URL, or the file name of an image. If we were working in a pure semantic web world I would be more inclined to go down the class based route but we have to also deal with instance data as if it were plain XML documents that we can use through TAPIR, validate with XML Schema and transform with XSLT. We could always change the definitions of the tdm:hasValue property (and the others) so that they inherit from a high level property. This kind of change is good because it doesn't affect the instance data. Have I understood your points correctly or have I just gone off on a circle explaining something that is completely off track? All the best, Roger Bob ------------------- from Roger ---------------------------------------------------------- Hi Markus, I have downsized the cc list for this discussion as I think it may be just confusing to the less technically focussed or otherwise involved people who would rather just hear the answer. I am not sure I totally follow you. Currently InfoItem.category property has a range of DefinedTerm which means anything that it should contain an instance of DefinedTerm - i.e. the simplified controlled vocabulary things we are using. It should perhaps have a range of http://rs.tdwg.org/ontology/voc/TDMTerm#TDMTerm. Are you suggesting that we have different InfoItem child classes one for each of the categories we are talking about (as listed here http://rs.tdwg.org/ontology/voc/TDMTerm)? So we would have <owl:Class rdf:ID="EvolutionInfoItem"> <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/ Base#InfoItem"/> </owl:Class> and <owl:Class rdf:ID="BehaviourInfoItem"> <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/ Base#InfoItem"/> </owl:Class> etc. And that instance data would look like this: <bii:BehaviourInfoItem> <ii:hasContent>Some stuff about behaviour</ii:hasContent> </bii:Behaviour> If you had evolutionary-behaviour data you might do this <bii:BehaviourInfoItem rdf:about="1233"> <rdf:type rdf:resource="http://rs.tdwg.org/ontology/voc/ EvolutionInfoItem#EvolutionInfoItem"/> <ii:hasContent>Some stuff about evolution of behaviour</ii:hasContent> </bii:Behaviour> Here we say that the thing 1233 is an instance of both classes. The same instance data the way we came up with it at the meeting would look like this: <tdm:InfoItem> <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Evolution"/> <tdm:category rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Behaviour"/> <tdm:hasContent>Some stuff about evolution of behaviour</ tdm:hasContent> </tdm:InfoItem> The attraction of doing it this way to me (and I think Donald suggested it) was that it is easy to write a client that will digest InfoItems without knowing what they are. If the client hadn't heard of Behaviour it could do nothing with a class based examples unless it was capable of exploring the class hierarchy and finding something it did know about and even then there may have been restrictions on the properties that it didn't understand. Effectively every client would need to know OWL. If an application (particular thematic network) really did want a BehaviourInfoItem class it could define one itself. <owl:Class rdf:ID="BehaviourInfoItem"> <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/ Base#InfoItem"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="tdm:category" /> <owl:hasValue rdf:resource="http://rs.tdwg.org/ontology/voc/ TDMTerm#Behaviour" /> </owl:Restriction> </owl:equivalentClass> </owl:Class> Which I believe would give the same inferences that would be found by going with subclasses (though I am no expert). The important thing is that we keep the instance data as simple and stable as possible and impose meaning later. If we were working in a pure semantic web world I would be more inclined to go down the class based route but we have to also deal with instance data as if it were plain XML documents that we can use through TAPIR, validate with XML Schema and transform with XSLT. We could always change the definitions of the tdm:hasValue property (and the others) so that they inherit from a high level property. This kind of change is good because it doesn't affect the instance data. Have I understood your points correctly or have I just gone off on a circle explaining something that is completely off track? All the best, Roger -------------- from Marcus --------------------------------------- Roger, thanks for this. The wiki guide really is a good advice and we should probably not use inheritance to model the domain ontology. We might use it carefully for more "technical" decisions like shared "global" properties, e.g. in the case of the Base#DefinedTerm class you created to derive all terms used for a controlled vocabulary from. But I still believe there is a difference from the Cat example in the wiki and the InfoItem class. The InfoItem class doesn't use concrete properties, like Cat::hasMarkings in your example, but rather uses a very flexible, generic property Info::hasValue or Info::hasContent. And exactly that abstraction makes me feel uncomfortable. We have to use another property "Info::category" to give semantics to the other value/content property. I doubt that any reasoner understands that (even if dont make use of them). The alternatives in my previous message don't have to use much of inheritance in any case. Applying A (using a common InfoItem Base Class) leaves us with the same situation that we have now. Instead of deriving terms in the domain ontology from Base#DefinedTerm we derive them from Base#InfoItem. And voila, we dont need the category property anymore. Applying "pattern B", i.e. deriving all properties from a base property, doesn't mean we have to use inheritance to model the domain. We can still derive all properties from a basic hasFact property for example. In this case (which I still feel is the most natural way of doing this) hasSize and hasDescription exist in parallel, but you would at least know they are a property of a taxon and that they have a value (either free text or a term from a list, using datatype or object property respectively). We would use inheritance mainly as a "technical" mean and not to model a hierarchy of properties for a taxon. -- Markus On 24.04.2007, at 18:54, Roger Hyam wrote: > > Hi Markus, > > I am glad you like it. Any resemblance to the Fact stuff in ABCD is > purely accidental ;). > >> (1) The first simple question is why we need a TDM class at all. >> Wouldn't it be sufficient to add an aboutTaxon property to the >> InfoItem class? > > This is the easy question. We need a container for sets of InfoItems > so that they can all be tagged with the same metadata. > Principle use case might be to get a set of info about a particular > taxon from a single provider and render it as a web page. > >> (2) If I understand TDM correctly, the TDM InformationItem class is >> kept independent from the real "domain" ontology (the fact category), >> which is linked from an InfoItem instance via the category property. >> On the other hand the property category is not part of the OWL >> language, so no reasoner will understand that the hasValue/hasContent >> property of an InfoItem instance really belongs to the domain >> ontology class. > > This raises a general modeling point and makes me realize that we > haven't written it down anywhere. I spent some time talking to Rob > Gales about it last year. I have written a wiki page that I hope > explains it. > > http://wiki.tdwg.org/twiki/bin/view/TAG/SubclassOrNot > > Please take a look, edit and feedback - perhaps to the TAG list. > > Subclassing properties is probably out as we have to allow for naive > implementations wherever possible. > > This may be way too techie for most of the audience. If we did change > the way we modeled it it may not have big implementations for the > 'domain experts' unless we ask them to produce a class hierarchy - > which may slow them down. > > Hope this helps, > > Roger > > > > On 23 Apr 2007, at 16:52, Markus Döring wrote: > >> Dear all, >> first of all I'd like to thank you guys for coming up with a nice RDF >> ontology for TDM! >> >> When taking a first look at it I couldn't exactly understand some >> modelling decisions though, so I would be happy if someone could shed >> light on my questions below that are based on this ontology: >> http://rs.tdwg.org/ontology/voc/TaxonDataModel.rdf >> >> I am still new to OWL ontologies, so I hope the following questions >> do not sound totally stupid. >> >> >> (1) The first simple question is why we need a TDM class at all. >> Wouldn't it be sufficient to add an aboutTaxon property to the >> InfoItem class? >> >> >> (2) If I understand TDM correctly, the TDM InformationItem class is >> kept independent from the real "domain" ontology (the fact category), >> which is linked from an InfoItem instance via the category property. >> On the other hand the property category is not part of the OWL >> language, so no reasoner will understand that the hasValue/hasContent >> property of an InfoItem instance really belongs to the domain >> ontology class. >> >> I can see two alternatives to this, so Im curious to know what you >> think about them. In case you have discussed them already, could >> someone explain to me why they were considered less appropriate? >> >> >> Alternative A) - InfoItem Base Class >> Derive all domain ontology classes from an InfoItem base class with >> properties (context, hasValue, ...) >> >> >> Alternative B) - TCS Object Properties Define the domain ontology >> mainly as object properties (similar to dublin core) that have a >> rdfs:domain=tcs:TaxonConcept and an rdfs:range that points to an >> InfoItem like base class that allows for context. We can define >> different InfoItem derived classes as ranges for some properties, >> allowing us to enforce free text >> (hasValue) or some specific controlled vocabulary (hasContent). >> The properties can also use inheritance to allow for broad and >> specialized descriptors. The TaxonConcept class already has some >> properties i.e. describedBy (for descriptive text) and >> circumscribedBy (specimen). These two properties could already serve >> as base properties to create specialised descriptors via >> rdfs:subPropertyOf. >> >> >> Well, as always there are many ways of doing the same thing. >> Best wishes >> Markus >> >> >> -- >> Markus Döring >> Botanic Garden and Botanical Museum Berlin Dahlem, >> Dept. of Biodiversity Informatics >> Königin-Luise-Str. 6-8, D-14191 Berlin >> +49 (30) 83850-284 >> m.doering(a)bgbm.org >> >> >> >> >> > ________________________________________________________________ Éamonn Ó Tuama, Ph.D. (eotuama(a)gbif.org), Senior Programme Officer for Data Access & Database Interoperability (DADI), Global Biodiversity Information Facility Secretariat, Universitetsparken 15, DK-2100 Copenhagen Ø, DENMARK Phone: +45 3532 1494; Fax: +45 3532 1480

2 3

[tdwg-ncd] NCD developments
by Neil Thomson 14 May '07

14 May '07

Dear all, Here is a short update on developments that are taking place with NCD. Wouter Addink and Ruud Altenburg at ETI are developing the NCD Toolkit and are currently ensuring that it will work with two languages - English plus a local language. Along with myself and Markus Döring in Berlin we are tidying up the NCD schema into a stable version to be used as the basis for the toolkit. The toolkit itself, along with the other developments outlined below, is expected to be ready for demonstration at this year's TDWG annual conference in mid-September. Markus is also working on the RDF aspects and integration with the TDWG ontology. He has added the emtpy basic classes of NCD to the TDWG ontology and is working on the following: http://rs.tdwg.org/ontology/voc/Collection.rdf http://rs.tdwg.org/ontology/voc/Institution.rdf http://rs.tdwg.org/ontology/voc/CollectionType.rdf http://rs.tdwg.org/ontology/voc/InstitutionType.rdf http://rs.tdwg.org/ontology/voc/ObjectType.rdf http://rs.tdwg.org/ontology/voc/PreservationMethodType.rdf Carol Butler at the Smithsonian is starting to assemble termlists for those elements that will benefit from having controlled vocabulary and these will also be integrated into the TDWG ontology. Connie Rinaldo at Harvard is working on the documentation set. She has reviewed the current introduction, documentation, and schema to see where changes need to be made. She has also reviewed the background TDWG material so that the new documentation will fit the TDWG standards. The implementation guide will be created in collaboration with ETI. I have completed the mapping of the Index Herbariorum data into NCD and next will be selecting which fields will be used so that an NCD Institution record can act as a business card for corporates in the biodiversity collections domain. The NCD 2007 Workshop will take place in June and the report from that will provide further details on progress. In the meantime, the list of deliverables for 2007 is available on the NCD wiki at: http://wiki.tdwg.org/twiki/bin/view/NCD/NCDListOfDeliverables With thanks, Neil --------- Neil Thomson NCD Interest Group Convenor

1 0

[taxon-model] Re: [tdwg-tag] Re: TDM Ontology
by Renato De Giovanni 12 May '07

12 May '07

Hi Roger, I'm not sure I share this vision of a "law of conservation of pain". It's true that one of the points in the other message was to ease the process of sharing data, but this doesn't mean that clients will necessarily have trouble (I hope not!). >>>From the TAPIR perspective, we handle extensibility by allowing providers to work with multiple conceptual schemas. If you produce a list of concepts from the TDM terms, anyone is free to produce other complementary lists in the future, without breaking compatibility. You know that in TAPIR it's also possible to produce outputs in different XML formats, even RDF. This should facilitate the work of clients. I suppose that clients will usually request data in formats that include elements that they know something about. But anyway, nothing prevents them to request things that they don't have any knowledge about. The TapirLink browser that I demonstrated during the TAPIR workshop is one of those clients: it dynamically builds an output model based on what the provider declared to have, and it simply displays this data in a tabular form. Now let's assume that we decide to work with a generic conceptual schema with two main concepts, category of InfoItem and InfoItem value. Let's also assume that providers will be able to easily share their data according to this conceptual model. In TAPIR, the output formats will be very limited - they will need to follow this generic approach. But let's suppose that this will not be a problem. What is going to happen is that clients will get amost anything from there - basically values of things that can be categorised in many ways. If clients want to perform validation they will need to do it themselves (the output format will be too generic, so we cannot use XML validation). Perhaps RDF validation will offer more possibilities, but then you're only considering data exchange in an RDF world. The meaning of InfoItems you would get from a dictionary of categories, in the same way that you could get the meaning of elements from a dictionary (DarwinCore for instance, or some ontology). In this case, it's not clear to me what would be the big benefits of using the generic model approach, but maybe I'm missing something. The more knowledge you have about the elements or concepts, the more interesting and powerful the applications will be. It's a philosophical issue. If we decide to avoid the more "traditional" way of structuring and modelling data because we feel it somehow limits our applications, then I think we first need to clearly understand what are these limitations. Otherwise, by doing things in a very different way we may miss the opportunity of using existing tools and resources - but still running the risk of facing again in a different road the same data structuring issues that we tried to avoid. Best Wishes, -- Renato PS: I'm sorry for crossposting. I'll send any follow-ups only to the new taxon-model mailing list: http://lists.tdwg.org/mailman/listinfo/taxon-model On 8 May 2007 at 9:35, Roger Hyam wrote: > > Renato, > > Thanks for your comments. That is an interesting view of the problem > and I think you may be correct for the supplier databases (though I > don't have first hand knowledge of these database schemas). Generally > the nearer the exchange format is to the supplier's schema the easier > it will be for them to publish. Taking the approach Markus suggests > would produce the result you are after I believe. > > There is just one problem that you didn't address. > > Who wants to consume the data and what do they want to do with it? > > To have something that is easy to produce, easy to consume and easy > to extend is more or less impossible. There has to be some pain > somewhere! > > What is your vision of a client application? How would it handle > elements it hadn't seen before - or is this not a requirement? > > All the best, > > Roger

5 4

[taxon-data-model] Notice: the group mailing list and wiki addresses have changed
by Ricardo Pereira 11 May '07

11 May '07

Dear Taxon Data Model group members, This is to inform you that the group mailing list web and email addresses as well as the group wiki web address have changed. The new addresses are: http://wiki.tdwg.org/TaxonDataModel (wiki homepage - short URL) http://wiki.tdwg.org/twiki/bin/view/TaxonDataModel/WebHome (wiki homepage - full URL) http://lists.tdwg.org/mailman/listinfo/taxon-data-model (mailing list information web page) taxon-data-model(a)lists.tdwg.org (mailing list web address) Please use the new email address above to post messages to all mailing list members. The old addresses of the resources above (that use the abbreviation Taxon Model, including the mailing list email address) have all been redirected to the new versions so that no external links are broken. The changes were made to address some concerns that have been raised that the abbreviation from Taxon Data Model to Taxon Model might lead to confusion and suggest that the group is concerned with taxonomy theory. Best regards, Ricardo Pereira TDWG Systems Administrator

1 0