October 2007 - tdwg-tag - lists.tdwg.org

[tdwg-guid] How to create resource that is not defined in Jena's vocabulary
by Chaohong Xie 28 Nov '07

28 Nov '07

Hi guys, I met the same problem as Peter wrote in the following link: http://lists.tdwg.org/pipermail/tdwg-guid/2006-September/000496.html. Unfortunately, I didn't get the final solution in it. I'm not sure Peter, Ben and Steve are still in this mail group or not. Anyway, can anybody help me solve this problem? Thanks a lot. My code is attached as well. What I want is outputing my vocabulary "Manifest" instead of "rdf:Description". Map<String, String> ns = new HashMap<String, String>(); ns.put("", "http://www.test.com/2007/08/test-vocabulary#"); ns.put("rdfs", "http://www.w3.org/2000/01/rdf-schema#"); ns.put("rdf", "http://www.w3.org/1999/02/22-rdf-syntax-ns#"); Model model = ModelFactory.createDefaultModel(); model.setNsPrefixes(ns); Resource r = model.createResource(" http://www.test.com/2007/08/test_config#MyNodeID").addProperty(model.createProperty("http://www.w3.org/1999/02/22-rdf-syntax-ns#type"), "http://www.test.com/2007/08/test-vocabulary#Manifest"); Property p = model.createProperty(" http://www.test.com/2007/08/test-vocabulary#created_by"); Statement s = model.createStatement(r, p, "Chaohong"); model.add(s); RDFWriter w = model.getWriter("RDF/XML-ABBREV"); w.setProperty("showXMLDeclaration", "true"); w.setProperty("tab", "2"); w.setProperty("xmlbase", "http://www.test.com/2007/08/test_config#"); w.write(model, System.out, "http://www.test.com/2007/08/test-vocabulary #"); Chaohong

2 1

[tdwg-guid] httpRange-14
by Jonathan Rees 15 Oct '07

15 Oct '07

Comment added to http://wiki.tdwg.org/twiki/bin/view/GUID/ LsidHttpProxyUsageRecommendation : (hope that's OK) If you are going to do this, I recommend that the http:// lsid.tdwg.org/... URIs result in 303 responses from the server. You want the LSIDs to denote domain objects, and you want the proxy HTTP URIs to denote the same things (that's what owl:sameAs means). But according to current semantic web practice, a 200-responding URI necessarily denotes the document (actually the "network resource"), so your current server behavior is saying something nonsensical, that a dog is a document. If you do a 303 See Other to a second URI that identifies the document carrying the RDF, then you'll be following W3C TAG recommendation httpRange-14 (see http://lists.w3.org/Archives/ Public/www-tag/2005Jun/0039.html) and your service will make semantic web tools and pedants happier, and no one will confuse a dog with a dogpile of RDF. -- Main.JonathanRees - 14 Oct 2007

2 2

RE: tdwg-tag Digest, Vol 22, Issue 5
by Eamonn O Tuama 12 Oct '07

12 Oct '07

Gregor's wrote: "That may be an excellent idea indeed. But then we should call it a "tag" and not "category" or "class", and make clear that adding multiple tags will remain uninterpretable - other than as you indicated." I don't really mind what we call our terms but if they are coming from a non-hierarchical, controlled vocabulary (a class?) (http://rs.tdwg.org/ontology/voc/SPMInfoItems.rdf) don't we leave open the possibility that these may eventually be arranged into an OWL ontology? Gregor's wrote: "That would mean an InfoItem = tagged free-form text, and a Distribution and OrganismInteraction class, which could be similar, but don't have to be, and may grow into different directions." So, both Gregor and Marcus are suggesting reducing the number of properties for an InfoItem to the following four (related properties in parentheses): - organismInteraction (associatedTaxon) - subjectTag (category, context, contextValue) - region (contextOccurrence) - info (hasContent, hasValue) I like the simplicity and do not think we are losing too much. Éamonn -----Original Message----- From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of tdwg-tag-request(a)lists.tdwg.org Sent: 10 October 2007 12:00 To: tdwg-tag(a)lists.tdwg.org Subject: tdwg-tag Digest, Vol 22, Issue 5 Send tdwg-tag mailing list submissions to tdwg-tag(a)lists.tdwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.tdwg.org/mailman/listinfo/tdwg-tag or, via email, send a message with subject or body 'help' to tdwg-tag-request(a)lists.tdwg.org You can reach the person managing the list at tdwg-tag-owner(a)lists.tdwg.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tdwg-tag digest..." Today's Topics: 1. Re: RE: tdwg-tag Digest, Vol 22, Issue 2 (Gregor Hagedorn) 2. Re: RE: tdwg-tag Digest, Vol 22, Issue 1 (Gregor Hagedorn) ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Oct 2007 09:48:47 +0200 From: "Gregor Hagedorn" <g.m.hagedorn(a)gmail.com> Subject: Re: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 2 To: tdwg-tag(a)lists.tdwg.org Message-ID: <5ebbead70710100048v4de595sf594cd36a3f4830d(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 > http://www.w3.org/TR/swbp-vocab-pub/ > Gregor will especially like it. :-) :-) Indeed, the document convinced me that http+purls+content negotiation (which is the chosen protocol for the semantic web!) would have been a better choice than LSIDs. The document is referenced on several Wiki pages, e.g. http://wiki.tdwg.org/twiki/bin/view/GUID/CommunityPracticesForHttp-basedGUID s; it helped me understand why the semantic web can be based on http at all and that the perceived problems, that initially lead us to opt for LSIDs, probably do not exist. Gregor ------------------------------ Message: 2 Date: Wed, 10 Oct 2007 10:00:20 +0200 From: "Gregor Hagedorn" <g.m.hagedorn(a)gmail.com> Subject: Re: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1 To: tdwg-tag(a)lists.tdwg.org Message-ID: <5ebbead70710100100j13d6a70ctd177ea11527fe30d(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 10/10/07, Eamonn O Tuama <eotuama(a)gbif.org> wrote: > Can't we keep the model simple and mandate that we are offering a faceted > classification, similar to a general tagging system like folksonomies? So a > particular InfoItem might have content which pertains to both genetics and > ecology and when tagged with those two categories, the only inference that > can be drawn is that the content is relevant to both. In a search, that > InfoItem would be returned for either of those categories, but is also very > likely to be appropriate to someone interested in "ecological genetics" who > would search on the categories "ecology + genetics" or vice versa. That may be an excellent idea indeed. But then we should call it a "tag" and not "category" or "class", and make clear that adding multiple tags will remain uninterpretable - other than as you indicated. What worries me is that too much seems to be desired in terms of using the vocabulary, i.e. we have been discussing what the category (and also the context...) could all be used for, and as I tried to show in my talk, sometimes the semantics of what subclasses or modifies what seem to be reversed already in the examples. My goal is to make this clear. The question remains what SPM is for. As you explain, it is more for finding information than algorithmically aggregating information. I understood the EOL/other taxon page use case to be about automatic aggregation. > In either case, I find it hard to see how anything useful can be derived > from such aggregations without human interpretation, e.g., someone preparing > a species page for EOL might harvest multiple InfoItems and arrange/edit > them as appropriate. Just being able to harvest data through the SPM is But that would be a one-time copy process. I think it would be important to clarify whether this is the use case or not. If it is, I am completely in favor of Eamonns "tagging approach". > surely helpful. In certain cases, where the domain might be restricted (an > invasive species group), the community may achieve more automated > aggregation by agreeing on how to use certain categories, e.g., I can see > benefit in being able to list multiple distributions of a particular species > one after the other, especially if biologists are tracking this over time > and the information is being continually updated. I think it would be beneficial to define specific kinds of infoitems for these use cases (especially distribution and organism interaction), to make it clear how the information is to be interpreted, and how it is extended. That would mean an InfoItem = tagged free-form text, and a Distribution and OrganismInteraction class, which could be similar, but don't have to be, and may grow into different directions. Essentially, this would allow to add further classes, which have even stronger differently structure for higher-structured data (categorical or quantitative data). How about that? Gregor ------------------------------ _______________________________________________ tdwg-tag mailing list tdwg-tag(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag End of tdwg-tag Digest, Vol 22, Issue 5 ***************************************

4 6

RE: tdwg-tag Digest, Vol 22, Issue 2
by Eamonn O Tuama 10 Oct '07

10 Oct '07

Marcus, I'm trying to relate your revised model below to the present description on http://rs.tdwg.org/ontology/voc/SpeciesProfileModel.rdf . You state - "The problem we saw with TAPIR is that there are only 2 new concepts defined by SPM - category and value. If you do not want to map anything more than this in TAPIR models, you probably can produce SPM RDF. " But what about the other properties defined for InfoItem - this is the full list: associatedTaxon category context contextOccurrence contextValue hasContent hasValue Are you suggesting that we drop 'associatedTaxon', the three context properties (context, contextOccurrence, contextValue) and the 'hasValue' property (information about a taxon in the form of a controlled vocabulary term), leaving just the 'category' and 'hasContent'. Is it possible to add additional columns in your database to accommodate these fields or do we run into trouble with TAPIR? Éamonn -----Original Message----- From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of tdwg-tag-request(a)lists.tdwg.org Sent: 09 October 2007 12:00 To: tdwg-tag(a)lists.tdwg.org Subject: tdwg-tag Digest, Vol 22, Issue 2 Send tdwg-tag mailing list submissions to tdwg-tag(a)lists.tdwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.tdwg.org/mailman/listinfo/tdwg-tag or, via email, send a message with subject or body 'help' to tdwg-tag-request(a)lists.tdwg.org You can reach the person managing the list at tdwg-tag-owner(a)lists.tdwg.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tdwg-tag digest..." Today's Topics: 1. Re: SPM Categories or Subclassing - again. (Gregor Hagedorn) 2. Re: SPM Categories or Subclassing - again. (D ? ring, Markus) ---------------------------------------------------------------------- Message: 1 Date: Mon, 8 Oct 2007 14:41:39 +0200 From: "Gregor Hagedorn" <g.m.hagedorn(a)gmail.com> Subject: Re: [tdwg-tag] SPM Categories or Subclassing - again. To: tdwg-tag(a)lists.tdwg.org Message-ID: <5ebbead70710080541l3cba340cyf2ebced50b4b9598(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" In SDD we used what is here called the "tagging approach", i.e. for descriptive concepts and characters we use <Text ref="some.resource.org/123"><Content>Free form text</Content></Text> In SDD, all element/attribute names refer to classes/attributes in UML or Java, whereas the xml values are corresponding values. Expressing concepts and characters as classes was considered impractical if the aim is generic software (classes are creatable at runtime, but at a price) because the number of characters is often very large. My experience shows that the number of character in identification sets varies between 50 and over 1000. Some studies in manual data integration (in LIAS) convinced me that the number of "integratable" characters is often less than imagined. A similar case study may also be the FRIDA data sets, which limit the number of common characters (common to all plant families) to 200, and from thereon use separate characters for each family. Clearly, when limiting the approach to just "very high level concepts", both class and value approaches are possible. The benefit of the SPM 0.2 approach is that it does enable reasoning (as well as may simplify tapir usage). However, as presented in Bratislava, I am doubtful that this limit holds. In my experience the limit between free form text and categorical data tends be diffuse rather than sharp and my intuition is that the SPM mechanism, being extensible, will be extended. I would like to note that the current TAG strategy is to provide both RDF and xml schema. The schema approach to SPM, however, seems to be more and more undesirable as the number of descriptive concepts grows. I have a question for TAPIR: Does TAPIR find it easier to search elements having specific attribute values than elements having child elements with specific value: <hasInformation> <InfoItem category="voc.x.org/DescriptiveConcepts/Size<http://some.resource.org/123>"> <....> </InfoItem> I might be useful to know. Although RDF allows this for literals, it seems to require the rdf:resource="" step for categorical data, so this may or may not help. ---------- PS: SDD calls the concepts "characters" based on the tradition and character is clearly inappropriate. However, Category to me seems to express nothing other than the type of the value. All contextValue and Value in SPM in version 0.2 refer to categories. Can anyone suggest a better term? What is the opposite of "value"? I can think of "Class" (value = instance), or - but perhaps too much limited to descriptions - "Feature" (also in GML). Anything else? Gregor ----------------------------------------------------- Gregor Hagedorn (G.M.Hagedorn(a)gmail.com) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Kvnigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203

2 1

RE: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1
by Eamonn O Tuama 10 Oct '07

10 Oct '07

Can't we keep the model simple and mandate that we are offering a faceted classification, similar to a general tagging system like folksonomies? So a particular InfoItem might have content which pertains to both genetics and ecology and when tagged with those two categories, the only inference that can be drawn is that the content is relevant to both. In a search, that InfoItem would be returned for either of those categories, but is also very likely to be appropriate to someone interested in "ecological genetics" who would search on the categories "ecology + genetics" or vice versa. I think an aggregator could do either of the following: 1) list an InfoItem under each of its categories - so it will appear multiple times 2) list InfoItems just once under concatenated categories (e.g., ecology+genetics) In either case, I find it hard to see how anything useful can be derived from such aggregations without human interpretation, e.g., someone preparing a species page for EOL might harvest multiple InfoItems and arrange/edit them as appropriate. Just being able to harvest data through the SPM is surely helpful. In certain cases, where the domain might be restricted (an invasive species group), the community may achieve more automated aggregation by agreeing on how to use certain categories, e.g., I can see benefit in being able to list multiple distributions of a particular species one after the other, especially if biologists are tracking this over time and the information is being continually updated. Éamonn -----Original Message----- From: Gregor Hagedorn [mailto:g.m.hagedorn@gmail.com] Sent: 09 October 2007 17:49 To: Eamonn O Tuama Subject: Re: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1 > I can see that it will be very difficult to come up with a set of > hierarchical terms that everyone will agree with. The subclassing approach, > unless we restrict it to one level (all classes are direct children of > InfoItem) is thus problematic. Is it possible to simply assign multiple > categories to an InfoItem? Something like the following statement - > This InfoItem has category "dispersal" and has category "asexual > reproduction". I wonder whether allowing multiple class or topic-categories is a good idea. It would allow a wealth of expressiveness, but it may be very difficult to interpret. Are "biology + reproduction" or morphology + reproduction" a subclass or intersection statement? By external knowledge I would assume the first is generalization, the second intersection, but this would be difficult to know. "Ecology + genetics" could be either aspects of both mixed, or precisely ecological genetics. Also: would the order be significant or not? Is "ecology + genetics" different from "genetics + ecology"? I wonder whether multiple topics per infoitem would not forfeit the purpose of SPM in relation to taxon page creation. It is unclear to me how in practice aggregators would deal with this. Gregor

4 3

RE: tdwg-tag Digest, Vol 22, Issue 2
by Eamonn O Tuama 10 Oct '07

10 Oct '07

Sorry, I only saw the latest additions to this thread now. The example database that Marcus presents represents a common way that people would be providing data. I think that if can agree on a common flat vocabulary of broad terms (as begun at the SPM workshop) we can at least provide his alphabetically sorted list of categorised statements back to a consumer (still pretty useful, I think). This could be expressed as a SKOS vocabulary as suggested by Roger but we could eventually take it further as he also suggests and develop and OWL ontology for reasoning over the categories. Gregor asked if TAPIR finds "it easier to search elements having specific attribute values than elements having child elements with specific value" like so - <hasInformation> <InfoItem category="voc.x.org/DescriptiveConcepts/Size<http://some.resource.org/123"> <....> </InfoItem> This could be important if we were to adopt a model where an InfoItem can have multiple categories, like so: <hasInformation> <InfoItem> <category="voc.x.org/DescriptiveConcepts/Dispersal<http://some.resource.org/ 123"/> <category="voc.x.org/DescriptiveConcepts/Reproduction<http://some.resource.o rg/123"/> <....> </InfoItem> Éamonn -----Original Message----- From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of tdwg-tag-request(a)lists.tdwg.org Sent: 09 October 2007 12:00 To: tdwg-tag(a)lists.tdwg.org Subject: tdwg-tag Digest, Vol 22, Issue 2 Send tdwg-tag mailing list submissions to tdwg-tag(a)lists.tdwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.tdwg.org/mailman/listinfo/tdwg-tag or, via email, send a message with subject or body 'help' to tdwg-tag-request(a)lists.tdwg.org You can reach the person managing the list at tdwg-tag-owner(a)lists.tdwg.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tdwg-tag digest..." Today's Topics: 1. Re: SPM Categories or Subclassing - again. (Gregor Hagedorn) 2. Re: SPM Categories or Subclassing - again. (D ? ring, Markus) ---------------------------------------------------------------------- Message: 1 Date: Mon, 8 Oct 2007 14:41:39 +0200 From: "Gregor Hagedorn" <g.m.hagedorn(a)gmail.com> Subject: Re: [tdwg-tag] SPM Categories or Subclassing - again. To: tdwg-tag(a)lists.tdwg.org Message-ID: <5ebbead70710080541l3cba340cyf2ebced50b4b9598(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" In SDD we used what is here called the "tagging approach", i.e. for descriptive concepts and characters we use <Text ref="some.resource.org/123"><Content>Free form text</Content></Text> In SDD, all element/attribute names refer to classes/attributes in UML or Java, whereas the xml values are corresponding values. Expressing concepts and characters as classes was considered impractical if the aim is generic software (classes are creatable at runtime, but at a price) because the number of characters is often very large. My experience shows that the number of character in identification sets varies between 50 and over 1000. Some studies in manual data integration (in LIAS) convinced me that the number of "integratable" characters is often less than imagined. A similar case study may also be the FRIDA data sets, which limit the number of common characters (common to all plant families) to 200, and from thereon use separate characters for each family. Clearly, when limiting the approach to just "very high level concepts", both class and value approaches are possible. The benefit of the SPM 0.2 approach is that it does enable reasoning (as well as may simplify tapir usage). However, as presented in Bratislava, I am doubtful that this limit holds. In my experience the limit between free form text and categorical data tends be diffuse rather than sharp and my intuition is that the SPM mechanism, being extensible, will be extended. I would like to note that the current TAG strategy is to provide both RDF and xml schema. The schema approach to SPM, however, seems to be more and more undesirable as the number of descriptive concepts grows. I have a question for TAPIR: Does TAPIR find it easier to search elements having specific attribute values than elements having child elements with specific value: <hasInformation> <InfoItem category="voc.x.org/DescriptiveConcepts/Size<http://some.resource.org/123>"> <....> </InfoItem> I might be useful to know. Although RDF allows this for literals, it seems to require the rdf:resource="" step for categorical data, so this may or may not help. ---------- PS: SDD calls the concepts "characters" based on the tradition and character is clearly inappropriate. However, Category to me seems to express nothing other than the type of the value. All contextValue and Value in SPM in version 0.2 refer to categories. Can anyone suggest a better term? What is the opposite of "value"? I can think of "Class" (value = instance), or - but perhaps too much limited to descriptions - "Feature" (also in GML). Anything else? Gregor ----------------------------------------------------- Gregor Hagedorn (G.M.Hagedorn(a)gmail.com) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Kvnigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203

4 4

RE: tdwg-tag Digest, Vol 22, Issue 1
by Eamonn O Tuama 09 Oct '07

09 Oct '07

Hi Roger, I can see that it will be very difficult to come up with a set of hierarchical terms that everyone will agree with. The subclassing approach, unless we restrict it to one level (all classes are direct children of InfoItem) is thus problematic. Is it possible to simply assign multiple categories to an InfoItem? Something like the following statement - This InfoItem has category "dispersal" and has category "asexual reproduction". I agree that it is restrictive to let a transport protocol dictate our data model but, in any case, there was a suggestion (from Donald I think) that we could make the category approach work by doing an inventory call first. SKOS allows the constructing of full blown ontologies but I take it you are suggesting that we restrict ourselves to just flat vocabulary lists. I like your idea of having OWL as an optional add-on to reason over our categories. Éamonn -----Original Message----- From: tdwg-tag-bounces(a)lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org] On Behalf Of tdwg-tag-request(a)lists.tdwg.org Sent: 08 October 2007 13:53 To: tdwg-tag(a)lists.tdwg.org Subject: tdwg-tag Digest, Vol 22, Issue 1 Send tdwg-tag mailing list submissions to tdwg-tag(a)lists.tdwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.tdwg.org/mailman/listinfo/tdwg-tag or, via email, send a message with subject or body 'help' to tdwg-tag-request(a)lists.tdwg.org You can reach the person managing the list at tdwg-tag-owner(a)lists.tdwg.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tdwg-tag digest..." Today's Topics: 1. SPM Categories or Subclassing - again. (Roger Hyam) 2. Re: SPM Categories or Subclassing - again. (Donald Hobern) ---------------------------------------------------------------------- Message: 1 Date: Mon, 8 Oct 2007 11:51:11 +0100 From: Roger Hyam <roger(a)tdwg.org> Subject: [tdwg-tag] SPM Categories or Subclassing - again. To: tdwg-tag(a)lists.tdwg.org Message-ID: <89F4B714-003E-4512-BCF3-8EA68BF0230E(a)tdwg.org> Content-Type: text/plain; charset="us-ascii" Hi All, I'd like to re-ignite a debate we had over the summer in the light of what was discussed at Bratislava and things I am thinking about now. The original way the Species Profile Model was structure was to have something like the attached UML diagram tagging.png

1 0

SPM Categories or Subclassing - again.
by Roger Hyam 08 Oct '07

08 Oct '07

Hi All, I'd like to re-ignite a debate we had over the summer in the light of what was discussed at Bratislava and things I am thinking about now. The original way the Species Profile Model was structure was to have something like the attached UML diagram tagging.png We didn't define a class "Category" but just left it as being any valid URI in the RDF style of doing things. Markus and several others pointed out that this would not work with TAPIR very well as all the InfoItems will look the same. Something like this: <SpeciesProfileModel> <hasInformation> <InfoItem> <category rdf:resource="some.resource.org/123" /> <....> </InfoItem> </hasInformation> <hasInformation> <InfoItem> <category rdf:resource="some.resource.org/124" /> <....> </InfoItem> </hasInformation> <hasInformation> <InfoItem> <category rdf:resource="some.resource.org/125" /> <....> </InfoItem> </hasInformation> </SpeciesProfileModel> The xpaths to the data represented by <...> would all be the same. They suggested something like the next diagram: Where info item is subclassed. This allows RDF to be serialized like this: <SpeciesProfileModel> <hasInformation> <Ecology> <....> </Ecology > </hasInformation> <hasInformation> <Behaviour> <....> </Behaviour> </hasInformation> <hasInformation> <BehaviouralEcology> <....> </BehaviouralEcology> </hasInformation> </SpeciesProfileModel> The xpaths to the <...> are all different and the model becomes TAPIR friendly. At the time I wasn't too bothered either way because I saw this as an artifact of serialization. The same thing could be written. <SpeciesProfileModel> <hasInformation> <InfoItem> <rdf:type rdf:resource="some.resource.org/Ecology" /> <....> </InfoItem> </hasInformation> <hasInformation> <InfoItem> <rdf:type rdf:resource="some.resource.org/Behaviour" /> <....> </InfoItem> </hasInformation> <hasInformation> <InfoItem> <rdf:type rdf:resource="some.resource.org/BehaviouralEcology" /> <....> </InfoItem> </hasInformation> </SpeciesProfileModel> With more or less that same meaning and looking just like a tagging example. This was a mistake on my part because of course it isn't the same meaning just a similar serialization - an RDF type really needs to point to a class and can't point to any old vocabulary that it could if it was treated like a tag. I have just added the category property back into InfoItem for discussion purposes. I am concerned about going down the subclassing route for a few reasons. 1) Building a class hierarchy is difficult. The discussions we had in Bratislava highlighted this. The examples put together in the current vocabulary sparked a debate as to how things should be organized. There are issues with the diamond problem in multiple inheritance - if contradictory semantics occur in multiple inheritance routes to a class which has priority? If we don't have multiple inheritance how do we have InfoItems that are about both Ecology and Behaviour for example or any other two subjects such as Dispersal and Asexual reproduction. 2) If a class hierarchy is required for analysis/inference it can be superimposed on a tag based transfer protocol using OWL necessary and sufficient properties. In fact this is arguably a better way of approaching the situation than building a class hierarchy a priori. 3) The motivation for going down the subclassing route is largely so it will work with the transport protocol - which sets alarm bells ringing for me. 4) It precludes us from using something like SKOS to build our categories. "SKOS or Simple Knowledge Organisation System is a family of formal languages designed for representation of thesauri, classification schemes, taxonomies, subject-heading systems, or any other type of structured controlled vocabulary. SKOS is built upon RDF and RDFS, and its main objective is to enable easy publication of controlled structured vocabularies for the Semantic Web. SKOS is currently developed within the W3C framework." (http://en.wikipedia.org/wiki/SKOS) I would really like to be able to say to "domain experts" that they "just" need to build a SKOS vocabulary for the terms used in their domain and then use the URIs of these terms for tagging information that is passed between providers than specify that they need to construct a more formal ontology of classes. I appreciate that one could argue that SKOS terms are like classes but they form part of a structure that is specifically designed for having the debates that TDWG needs to have around the vocabulary part of the standards (rather than the exchange parts). I would be grateful for peoples thoughts and criticisms. All the best, Roger

4 3