May 2007 - tdwg-tag - lists.tdwg.org

Request for Comments on LSID HTTP Proxy Usage Recommendations
by Ricardo Pereira 24 May '07

24 May '07

Dear TDWG GUID and TAG members, The TDWG Infrastructure Project (TIP) Team is putting forward a proposal to make Life Science Identifiers (LSID) more interoperable with standard World Wide Web and Semantic Web applications. In that proposal we recommend the use of LSID HTTP proxies to simplify the resolution process for tools that do not yet handle LSIDs directly. The proposal is available at http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRecommendation We would like to ask you to please review the proposal and give us feedback. Comments can be added directly to the wiki page above or sent to either the tdwg-tag or tdwg-guid mailing list. I will move the comments from the mailing lists to the wiki page as they become available. When we reach consensus on the relevance and content of the proposal, we intend to include it on the TDWG LSID Applicability Statement and move forward to ratify it as a TDWG standard. We really appreciate your feedback. Best regards, Ricardo Pereira Roger Hyam Donald Hobern Lee Belbin TDWG Infrastructure Project (TIP) Team

2 2

[tdwg-tapir] Minor changes
by Renato De Giovanni 22 May '07

22 May '07

Dear all, Yesterday I finally managed to produce valid ABCD output from an instance of TapirLink that has mapped DarwinCore concepts. It could be possible to achieve this before by using a simplified XML Schema for ABCD, but I wanted to use the official one. The corresponding output model (inside our repository under cs/dwc/1.4/models) still needs to include more mappings between ABCD and DarwinCore elements, but it already works with the most important concepts. One of the things that I needed to do was to create more environment variables to be used by output models, because there are mandatory elements in ABCD that don't correspond to any DarwinCore concept. However, they do correspond to TAPIR metadata elements. The current TAPIR specification recognizes the following environment variables: date timestamp dataSourceName accessPoint lastUpdated I created these new ones in TapirLink, not only because of ABCD but also for the RSS2 output model: dateCreated metadataLanguage dataSourceLanguage dataSourceDescription rights technicalContactName technicalContactEmail contentContactName contentContactEmail If the specification doesn't include these variables, they will remain unofficial and this situation may not be good for future interoperability. So one of the things I would like to suggest is to include these variables in the controlled vocabulary defined by TAPIR. Please let me know if this is OK and if you have more suggestions. (Markus, sometime ago there was the idea of including all TAPIR metadata as environment variables so that they could also be returned in search responses, would you like to suggest more variables?). Remember that TAPIR environment variables are optional (providers don't need to support them) and extensible (providers can define new variables if they want to). Here are two other minor changes suggested to the protocol and raised by issues that were found during the development of TAPIR tools for the GISIN network: * Restrict POST requests to "application/x-www-form-urlencoded" (the default POST encoding). Reason: TAPIR requests can include multiple parameters with the same name ("concept" and "tagname" in the inventory operation) but some languages like PHP cannot handle this properly - only the last parameter becomes available from the $_REQUEST global variable. In these cases it is necessary to manually extract the parameters and this doesn't seem to be an easy task if POST is used with "multipart/form-data". Since this last encoding is mostly used for sending large quantities of binary data, which is definitely not the case of a TAPIR request, I think we can safely avoid it. * Include an optional attribute "alias" in output models and query templates that are advertised in capabilities responses. The CNS configuration file already allows aliases for output models and query templates, but these are not present in capabilities responses as it happens with concept and schema aliases. Please let me know if you have any comments, suggestions or objections to these changes, otherwise I'll take the liberty to make them in the next few days. Best Regards, -- Renato

2 3

[tdwg-tapir] Hosting strategies
by Roger Hyam 15 May '07

15 May '07

Hi Everyone, There is a requirement that all wrapper type applications (TAPIR, DiGIR, BioCASe and others) have but that I don't think we address. All instances need to have: Either a database on a server in a DMZ or with an ISP with the ability to export data from the production database to the public database and then keep changes in the production database synchronize with the public database. Or the ability to provide a secured/restricted connection directly to production database through the firewall. Configuring the wrapper software against a database seems a smaller problem than getting a handle on an up to date database to configure it against! Should we have a recommended strategy or best practice for overcoming these problems? Do we have any figures on how they are overcome in the existing BioCASe and DiGIR networks? Many thanks for your thoughts, Roger

6 8

RE: [tdwg-tapir] Executive summary available
by rupertwilson＠rhs.org.uk 15 May '07

15 May '07

Hi Renato, This is a great summary; we should definitely have more of these on the TDWG site! I just wonder if maybe there could be a couple more examples of how TAPIR might work in the real world which would help persuade executive managers to get their organisations involved? Oh I also spotted a typo in the first URL for TDWG under "More information", it needs an extra 'w' Cheers Rupert Principal Data Manager, Science & Learning, Royal Horticultural Society Garden Wisley, Woking, Surrey. GU23 6QB UK -----Original Message----- From: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of Renato De Giovanni Sent: 15 May 2007 15:10 To: tdwg-tapir(a)lists.tdwg.org Subject: [tdwg-tapir] Executive summary available Hi again, I forgot to say that now there's an executive summary about TAPIR: http://www.tdwg.org/activities/tapir/executive-summary/ Comments and suggestions are welcome. All the best, -- Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir <p style="margin-top: 0; margin-bottom: 0"> <img src="http://www.rhs.org.uk/images/email/green.jpg"> <font size="3" color="#008000">Please consider the environment before printing this e-mail.</font> </p> <p style="margin-top: 0; margin-bottom: 0">The contents of this email and any files transmitted with it are confidential, proprietary and may be legally privileged. They are intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email. The sender is not responsible for any changes made to any part of this email after transmission. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Society. Although this email and any attachments are believed to be free from any virus or other defects which might affect any computer or IT system into which they are received, no responsibility is accepted by the Society or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The Royal Horticultural Society (RHS) is the UK’s leading gardening charity dedicated to advancing horticulture and promoting good gardening. Anyone with an interest in gardening can enjoy the benefits of RHS membership and help us to secure a healthy future for gardening. For more information call: 0845 130 4646, or visit <a href="http://www.rhs.org.uk">http://www.rhs.org.uk</A> Reg charity no. 222879 </p>

2 1

[tdwg-tapir] Executive summary available
by Renato De Giovanni 15 May '07

15 May '07

Hi again, I forgot to say that now there's an executive summary about TAPIR: http://www.tdwg.org/activities/tapir/executive-summary/ Comments and suggestions are welcome. All the best, -- Renato

1 0

[tdwg-tapir] RE: [PyWrapper-devel] Query Result
by "Döring, Markus" 14 May '07

14 May '07

I was thinking about that too. We already have that in the BioCASE software. But the problem with TAPIR is that the concepts you map to are themselves *not* mandatory. Only the output model which is used in a request states that a certain concept is required. So basically any ABCD or Darwin Core concept could be mandatory. The only way around I see is to use a "canonical" model in the back to do the mapping, i.e. the model which looks exactly like the schema that is used to define concepts. This is an item on pywrappers requested feature list, but I dont have time to do anything about it soon I am afraid. http://trac.pywrapper.org/pywrapper/ticket/97 thanks, markus -----Original Message----- From: pywrapper-devel-bounces(a)lists.sourceforge.net on behalf of Shunde Zhang Sent: Mon 5/14/2007 8:22 AM To: PyWrapper Developers mailing list Cc: Subject: Re: [PyWrapper-devel] Query Result Hi Markus, Thanks for your reply. I finally got it working. Since I don't know which concept is compulsory, I just missed some concepts. It would be good if I add a schema to the mapping, those must-have concepts will be added by default so that I don't need to look for them from the long long list. Sorry the system is in our intranet, so you cannot access it. Thanks anyway. Cheers, Shunde. Quoting Markus Döring <m.doering(a)bgbm.org>: > Dear Shunde, > the problem is found in the diagnostics here: > > "The element /DataSets/DataSet..Sequence:-1360356980 was dropped 1 > times because of missing required subelements or attributes: > [u'TechnicalContacts']" > > This means that ABCD defines a mandatory element TechnicalContacts > that cannot be created. This usually results of missing mappings or > NULL in the data of that specific record. Is the configuration tool > externally visible? Then we (support(a)biocase.org) could check your > mappings directly online. > > best wishes > -- > Markus > > > > On 10.05.2007, at 04:55, Shunde Zhang wrote: > > > Hi all, > > > > I just installed pywrapper 3.1.0a, and set up a simple mapping to > > ABCD 2.06. > > > > I now have mapped 8 concepts. and when I did a simple query, I got > > the correct > > number of records but not the content as below. I used Query Forms > > to do this. > > Could you please tell me if anything wrong with my config? Thanks a > > lot. > > > > Cheers, > > Shunde. > > > > > > <response xsi:schemaLocation="http://rs.tdwg.org/tapir/1.0 > > http://rs.tdwg.org/tapir/1.0/schema/tapir.xsd"> > > - > > <header> > > - > > <source sendtime="2007-05-10T12:14:09.34" > > accesspoint="http://ristretto.sapac.edu.au:8088/pywrapper/pywrapper? > > dsa=avh"> > > <software version="3.1.0alpha" name="PyWrapper"/> > > </source> > > - > > <custom> > > <pyw:webapps pyw:location="http://ristretto.sapac.edu.au:8088/ > > pywrapper"/> > > </custom> > > </header> > >  > > - > > <search> > > <summary start="0" totalMatched="1"/> > > </search> > >  > > - > > <diagnostics> > > <diagnostic time="2007-05-10T12:18:21.15" level="INFO">Reading > > request</diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:21.21" level="INFO"> > > Read model http://rs.tdwg.org/tapir/cs/abcd/2.06/model/abcd206.xml > > </diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:22.22" level="INFO"> > > Parsed response structure contains 991 leaf concepts with type out > > of 1663 nodes > > in total > > </diagnostic> > > <diagnostic time="2007-05-10T12:18:22.91" level="INFO">Request fully > > parsed</diagnostic> > > <diagnostic time="2007-05-10T12:18:22.91" level="INFO">Init model > > ACBD 2.06 with > > datasource preferences</diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:23.26" level="INFO"> > > Model init finished. The model contains 1324 mapped concepts for > > datasource > > 'avh' out of 1324 model nodes mapped. > > </diagnostic> > > <diagnostic time="2007-05-10T12:18:23.26" level="INFO">Update model > > structure > > with datasource preferences</diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:26.11" level="INFO"> > > Executing SQL: "SELECT COUNT(DISTINCT SpecimenRecord.Id) FROM > > SpecimenRecord AS > > SpecimenRecord JOIN TaxonName AS TaxonName ON > > SpecimenRecord.TaxonNameId = > > TaxonName.Id WHERE TaxonName.FullScientificName LIKE 'Baccharis > > pingraea' " > > </diagnostic> > > <diagnostic time="2007-05-10T12:18:41.22" level="INFO">DB query > > finished</diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:41.22" level="INFO"> > > Ordering view by [TaxonName.FullScientificName(text)] > > </diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:41.23" level="INFO"> > > Executing SQL: "SELECT DISTINCT SpecimenRecord.Id FROM > > SpecimenRecord AS > > SpecimenRecord JOIN TaxonName AS TaxonName ON > > SpecimenRecord.TaxonNameId = > > TaxonName.Id WHERE TaxonName.FullScientificName LIKE 'Baccharis > > pingraea' ORDER > > BY TaxonName.FullScientificName, SpecimenRecord.Id LIMIT 51 OFFSET 0" > > </diagnostic> > > <diagnostic time="2007-05-10T12:18:54.29" level="INFO">DB query > > finished</diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:54.29" level="INFO"> > > Executing SQL: "SELECT TaxonName.FullScientificName, > > SpecimenRecord.Id, > > SpecimenRecord.SourceInstitutionID, SpecimenRecord.UnitId, > > SpecimenRecord.DateLastEdited, TaxonName.Id, TaxonName.Genus, > > TaxonName.Species, > > CollectSite.Id, CollectSite.LongitudeDecimal, > > CollectSite.LatitudeDecimal FROM > > SpecimenRecord AS SpecimenRecord LEFT JOIN TaxonName AS TaxonName ON > > SpecimenRecord.TaxonNameId = TaxonName.Id LEFT JOIN CollectSite AS > > CollectSite > > ON SpecimenRecord.CollectSiteId = CollectSite.Id WHERE > > SpecimenRecord.Id IN > > ('459464') ORDER BY TaxonName.FullScientificName " > > </diagnostic> > > <diagnostic time="2007-05-10T12:18:54.32" level="INFO">DB query > > finished</diagnostic> > > <diagnostic time="2007-05-10T12:18:54.32" level="INFO">Create XML > > content from > > recordset</diagnostic> > > <diagnostic time="2007-05-10T12:18:54.32" level="INFO">Use > > intelligent model > > interpreter</diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:54.32" level="WARNING"> > > No content produced. Probably there were no matches for your query. > > </diagnostic> > > <diagnostic time="2007-05-10T12:18:54.32" level="INFO">Finished > > creating XML > > content</diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:54.32" level="INFO"> > > Total number of elements created=0. Elements dropped=0 > > </diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:54.33" level="WARNING"> > > The element /DataSets..Sequence:-1360356532 was dropped 1 times > > because of > > missing required subelements or attributes: [u'DataSet'] > > </diagnostic> > > - > > <diagnostic time="2007-05-10T12:18:54.33" level="WARNING"> > > The element /DataSets/DataSet..Sequence:-1360356980 was dropped 1 > > times because > > of missing required subelements or attributes: [u'TechnicalContacts'] > > </diagnostic> > > </diagnostics> > > </response> > > > > ---------------------------------------------------------------------- > > --- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > PyWrapper-devel mailing list > > PyWrapper-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > PyWrapper-devel mailing list > PyWrapper-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ PyWrapper-devel mailing list PyWrapper-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pywrapper-devel

2 1

Re: TDM Ontology
by Roger Hyam 08 May '07

08 May '07

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 On 4 May 2007, at 10:56, Markus Döring wrote: > 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 > > > >> >> All the best, >> >> Roger >> >> >> On 2 May 2007, at 16:21, Markus Döring wrote: >> >>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > >

5 8

RE: [tdwg-tag] Re: TDM Ontology
by William Ulate 04 May '07

04 May '07

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? -----Original Message----- From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of Bob Morris Sent: Viernes, 04 de Mayo de 2007 11:17 a.m. To: Renato De Giovanni Cc: Benjamin Clark; Andreas Kohlbecker; tdwg-tag(a)lists.tdwg.org; Éamonn Ó Tuama Subject: [tdwg-tag] Re: TDM Ontology 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 > > Best Regards, > -- > Renato > >> -- 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

1 0