DC: was Re: Re-organisation of TDWG Ontology: Danger silence will == acquiescence!
Sometimes DC works and sometimes it doesn't. See http://www.keytonature.eu/wiki/MRTG_Schema_v0.7 where we spent and continue to spend a lot of effort to sort out (in the case of multimedia resources) what does and doesn't. I hope people will join that discussion. At the simplest level, what we do is use DC (and other standards) URI's for the URI of the term we are adopting. Some DC remains very vague and sloppy, even in the 2008 revision. The current "controversy" on the MRTG wiki is whether too much complexity gets introduced by trying to provide for data provenance. To me, this is an issue very important for science data, but only somewhat so in the communities classically served by DC---the cultural artifacts community possibly being the biggest exception.
Bob
On Tue, May 12, 2009 at 10:17 AM, Roderic Page r.page@bio.gla.ac.uk wrote:
Dear Roger, This is probably off topic (and maybe I missed something), but it really worries me that much of the TDWG vocabulary is unique to TDWG. Journal publishers are busy pumping out Dublin Core and PRISM (sometimes with FOAF). I'm trying to link this to records nomenclators pump out. I seem to recall some statement that where possible TDWG would reuse existing vocabularies, but I don't see this happening. In the meantime, I'm busy mapping our idiosyncratic vocabulary to that used by publishers.
Regards
Rod
On 12 May 2009, at 09:59, Roger Hyam wrote:
Hi All, I need to do some work on the Taxon Name and Taxon Concept vocabularies and believe I have come up with a good way of organising the TDWG ontology space (everything within http:/rs.tdwg.org/ontology).
The following are the changes I suggest:
- All files should be OWL DL compliant
- All files should be openable in Protege 4 (I believe this is now good
enough to use for editing these small ontologies)
- We take a highly structured modular approach I call this the Bricks
and Mortar design pattern - Some files are 'Bricks' and as such *import or reference no other files, classes or individuals*. e.g. TaxonName does not mention a higher 'Name' object in the class hierarchy. - Other files are 'Mortar'. These files import Bricks and stipulate relationships between things. Because we are using OWL it is easy to define things like the class hierarchy or the range of a property in a separate file to the file the original class or property was defined in. - This pattern gives us maximum re-usability as the same Brick could be used in different ways. It does not bind us to any one implementation of one object. - An example of the usage pattern would be to define TaxonName, TaxonConcept, Rank, NomenclaturalCode as separate bricks that don't reference each other at all then create a TCS ontology that imports these 4 bricks and defines their relationships.
- We move to some other method of presenting the ontologies on line -
possibly the OWLDoc plug-in for Protege. This would lose us the branded look we have at the moment but would be more flexible and consistent in the long run.
As I need to do this for the TaxonName TaxonConcept vocabularies I volunteer to do manage the space this year if people are happy going down this route.
From the point of view of deployed systems (the nomenclators) there may be a need for a namespace change on some properties but I would review what is in use and this would be trivial - if necessary at all.
What do you think? I will take silence as acquiescence on the grounds that any movement is better than none - though I don't suppose I will get round to doing anything about changes till after e-Biosphere in June.
All the best,
Roger
Roger Hyam - Project Officer WP4 Pan European Species Infrastructure
+44 75 90 60 80 16
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Bob,
There is a difference between namespace re-use and importing of ontologies. When it comes to inference it depends on whether your inference engine goes off and pulls in the ontologies associated with the namespace or whether you override it in some way.
For good data provenance you need a crystal ball. Only after the event do you know what information should have been recorded in order to enable you to answer that all important question that has only now occurred to you. If we only knew how tall the photographer was we could ..... Which version of which software library compiled on which architecture was used to compress this image? Without a crystal ball you have to record everything just incase and I figure the law of diminishing returns kicks in pretty quickly.
Roger
On 12 May 2009, at 15:28, Bob Morris wrote:
Sometimes DC works and sometimes it doesn't. See http://www.keytonature.eu/wiki/MRTG_Schema_v0.7 where we spent and continue to spend a lot of effort to sort out (in the case of multimedia resources) what does and doesn't. I hope people will join that discussion. At the simplest level, what we do is use DC (and other standards) URI's for the URI of the term we are adopting. Some DC remains very vague and sloppy, even in the 2008 revision. The current "controversy" on the MRTG wiki is whether too much complexity gets introduced by trying to provide for data provenance. To me, this is an issue very important for science data, but only somewhat so in the communities classically served by DC---the cultural artifacts community possibly being the biggest exception.
Bob
On Tue, May 12, 2009 at 10:17 AM, Roderic Page r.page@bio.gla.ac.uk wrote: Dear Roger,
This is probably off topic (and maybe I missed something), but it really worries me that much of the TDWG vocabulary is unique to TDWG. Journal publishers are busy pumping out Dublin Core and PRISM (sometimes with FOAF). I'm trying to link this to records nomenclators pump out. I seem to recall some statement that where possible TDWG would reuse existing vocabularies, but I don't see this happening. In the meantime, I'm busy mapping our idiosyncratic vocabulary to that used by publishers.
Regards
Rod
On 12 May 2009, at 09:59, Roger Hyam wrote:
Hi All,
I need to do some work on the Taxon Name and Taxon Concept vocabularies and believe I have come up with a good way of organising the TDWG ontology space (everything within http:/ rs.tdwg.org/ontology).
The following are the changes I suggest:
All files should be OWL DL compliant All files should be openable in Protege 4 (I believe this is now good enough to use for editing these small ontologies) We take a highly structured modular approach I call this the Bricks and Mortar design pattern Some files are 'Bricks' and as such import or reference no other files, classes or individuals. e.g. TaxonName does not mention a higher 'Name' object in the class hierarchy. Other files are 'Mortar'. These files import Bricks and stipulate relationships between things. Because we are using OWL it is easy to define things like the class hierarchy or the range of a property in a separate file to the file the original class or property was defined in. This pattern gives us maximum re-usability as the same Brick could be used in different ways. It does not bind us to any one implementation of one object. An example of the usage pattern would be to define TaxonName, TaxonConcept, Rank, NomenclaturalCode as separate bricks that don't reference each other at all then create a TCS ontology that imports these 4 bricks and defines their relationships. We move to some other method of presenting the ontologies on line - possibly the OWLDoc plug-in for Protege. This would lose us the branded look we have at the moment but would be more flexible and consistent in the long run.
As I need to do this for the TaxonName TaxonConcept vocabularies I volunteer to do manage the space this year if people are happy going down this route.
From the point of view of deployed systems (the nomenclators) there may be a need for a namespace change on some properties but I would review what is in use and this would be trivial - if necessary at all.
What do you think? I will take silence as acquiescence on the grounds that any movement is better than none - though I don't suppose I will get round to doing anything about changes till after e-Biosphere in June.
All the best,
Roger
Roger Hyam - Project Officer WP4 Pan European Species Infrastructure
+44 75 90 60 80 16
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
-- Robert A. Morris Professor of Computer Science UMASS-Boston ram@cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/~ram/calendar.html phone (+1)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
Yes, and I am trying to get my head around this in my early attempts to OWLify MRTG. This actually brings me to an owl design question I immediately ran into. Until the point of applying a reasoner, it is not supposed to matter whether referenced ontologies are resolvable or not, but with Protege4 I found it easier to import the third party ontologies that I wanted to reference. Protege 4 resolves imports if the URI is a URL to some RDF. This made it easier for me to see how MRTG issues should relate to, e.g. dc issues in my desire to capture the informally stated relationships we put in the MRTG normative document (i.e. vocabularies in http://www.keytonature.eu/wiki/MRTG_Schema_v0.7) I am still left with the following design question:
Loosely, the question is: to capture an intent to re-use something like dc, should an ontology locally retarget the original property by restricting its domain, or should it define a new property and declare it to be owl:equivalentProperty to the original. For example, MRTG has an Identifier attribute of a MediaResource that is supposed to uniquely identify the resource.
One possibility is
<owl:DatatypeProperty rdf:about="dcterms:identifier"> <rdfs:domain rdf:resource="#MediaResource"/> </owl:DatatypeProperty>
This would let MRTG instance documents really reference dcterms:identifier and sidestep any mapping requirements in integration with resources already described by dc. It would also prohibit a MRTG valid description of a MediaResource have no other use of dcterms:identifier, which is probably a Good Thing for reasoning.
Another is (note upper case I in Identifier)
<owl:DatatypeProperty rdf:about="#Identifier"> <rdf:type rdf:resource="owl:FunctionalProperty"/> <owl:equivalentProperty rdf:resource=dcterms:identifier"/> <rdfs:domain rdf:resource="#MediaResource"/> <rdfs:range rdf:resource="xsd:anyURI"/> </owl:DatatypeProperty>
Is it easy to give a simple example of an axiom that would be consistent with one of these and inconsistent with another?
If in fact they are logically equivalent, is one of them better than the other on some other grounds?
Assume that dcterms is imported and resolved. Does the owl:equivalentProperty guarantee these two models must be logically equivalent?
For purposes of this question, ignore for the moment that dcterms:identifier actually has range xsd:Literal and is not declared a FunctionalProperty in the 2008 dcterms rdf. Also, pretend that it has the same range type that MRTG is after...a not entirely clear issue in itself...
Thanks
Bob p.s. I'm thinking that MRTG wiki needs some pages about modeling and representation and that questions like this belong there and/or on some related, more general, TDWG wiki... but which?
On Thu, May 14, 2009 at 8:37 AM, Roger Hyam rogerhyam@mac.com wrote:
Bob,
There is a difference between namespace re-use and importing of ontologies. When it comes to inference it depends on whether your inference engine goes off and pulls in the ontologies associated with the namespace or whether you override it in some way.
For good data provenance you need a crystal ball. Only after the event do you know what information should have been recorded in order to enable you to answer that all important question that has only now occurred to you. If we only knew how tall the photographer was we could ..... Which version of which software library compiled on which architecture was used to compress this image? Without a crystal ball you have to record everything just incase and I figure the law of diminishing returns kicks in pretty quickly.
Roger
On 12 May 2009, at 15:28, Bob Morris wrote:
Sometimes DC works and sometimes it doesn't. See http://www.keytonature.eu/wiki/MRTG_Schema_v0.7 where we spent and continue to spend a lot of effort to sort out (in the case of multimedia resources) what does and doesn't. I hope people will join that discussion. At the simplest level, what we do is use DC (and other standards) URI's for the URI of the term we are adopting. Some DC remains very vague and sloppy, even in the 2008 revision. The current "controversy" on the MRTG wiki is whether too much complexity gets introduced by trying to provide for data provenance. To me, this is an issue very important for science data, but only somewhat so in the communities classically served by DC---the cultural artifacts community possibly being the biggest exception.
Bob
On Tue, May 12, 2009 at 10:17 AM, Roderic Page r.page@bio.gla.ac.ukwrote:
Dear Roger, This is probably off topic (and maybe I missed something), but it really worries me that much of the TDWG vocabulary is unique to TDWG. Journal publishers are busy pumping out Dublin Core and PRISM (sometimes with FOAF). I'm trying to link this to records nomenclators pump out. I seem to recall some statement that where possible TDWG would reuse existing vocabularies, but I don't see this happening. In the meantime, I'm busy mapping our idiosyncratic vocabulary to that used by publishers.
Regards
Rod
On 12 May 2009, at 09:59, Roger Hyam wrote:
Hi All, I need to do some work on the Taxon Name and Taxon Concept vocabularies and believe I have come up with a good way of organising the TDWG ontology space (everything within http:/rs.tdwg.org/ontology).
The following are the changes I suggest:
- All files should be OWL DL compliant
- All files should be openable in Protege 4 (I believe this is now
good enough to use for editing these small ontologies)
- We take a highly structured modular approach I call this the Bricks
and Mortar design pattern - Some files are 'Bricks' and as such *import or reference no other files, classes or individuals*. e.g. TaxonName does not mention a higher 'Name' object in the class hierarchy. - Other files are 'Mortar'. These files import Bricks and stipulate relationships between things. Because we are using OWL it is easy to define things like the class hierarchy or the range of a property in a separate file to the file the original class or property was defined in. - This pattern gives us maximum re-usability as the same Brick could be used in different ways. It does not bind us to any one implementation of one object. - An example of the usage pattern would be to define TaxonName, TaxonConcept, Rank, NomenclaturalCode as separate bricks that don't reference each other at all then create a TCS ontology that imports these 4 bricks and defines their relationships.
- We move to some other method of presenting the ontologies on line -
possibly the OWLDoc plug-in for Protege. This would lose us the branded look we have at the moment but would be more flexible and consistent in the long run.
As I need to do this for the TaxonName TaxonConcept vocabularies I volunteer to do manage the space this year if people are happy going down this route.
From the point of view of deployed systems (the nomenclators) there may be a need for a namespace change on some properties but I would review what is in use and this would be trivial - if necessary at all.
What do you think? I will take silence as acquiescence on the grounds that any movement is better than none - though I don't suppose I will get round to doing anything about changes till after e-Biosphere in June.
All the best,
Roger
Roger Hyam - Project Officer WP4 Pan European Species Infrastructure
+44 75 90 60 80 16
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
-- Robert A. Morris Professor of Computer Science UMASS-Boston ram@cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/%7Eram http://www.cs.umb.edu/~ram/calendar.htmlhttp://www.cs.umb.edu/%7Eram/calendar.html phone (+1)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org
Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/
Hi Bob,
I think these are general OWL questions that belong on OWL message boards. If you would like to go and frame it there, expand your mind and come back and tell us the answer that would be great. But here are my thoughts anyhow.
Firstly why are we defining dcterms:identifier as having a domain of MediaResource? This entails, for any importing ontology, that dcterms:identifier is a property of MediaResource and therefore something that has a dcterms:identifier is a MediaResource.
[An analogy: if hasTopping has the domain Pizza and range PizzaTopping we are safe to assume that if "VeggieWopper hasTopping Onion" then a VeggieWopper is a Pizza and a Onion is a kind of PizzaTopping. If they aren't we get an inconsistency.]
Presumably dcterm:identifier could be used for lots of things that aren't MediaResources that might be imported into our ontologies. We don't want to assert that these other things are also MediaResources so we shouldn't assert that dcterms:identifier has a domain of MediaResources.
This is why DC don't specify a range - so you can apply it to anything without asserting what kind of thing it is.
We don't have to define a domain for dcterms:identifier for people to tag MediaResources with it. They can just do it. They may use all sorts of vocabularies to assert things about their MediaResources.
The problem that I don't have a compelling answer to is: How do we tell people we would like them to tag their instances of MediaResource with dcterms:identifier without entailing anything in our ontology?
The only answer I have to this question is: Documentation and examples - which isn't sexy and compelling.
One could go down the subPropertyOf route to make our own property with the domain of MediaResource but I feel uncomfortable with this as we are not subclassing the meaning of dcterms:identifier - I presume we really do mean it in the sense of Dublin Core.
The rule of thumb is: Think before you assert. If in doubt don't assert anything. All those aphorisms about he who keeps quite knows the most probably apply to ontologies. Small succinct statements are the most powerful. - So why isn't this post shorter I hear you say :)
Hope this helps,
Roger
On 14 May 2009, at 14:35, Bob Morris wrote:
Yes, and I am trying to get my head around this in my early attempts to OWLify MRTG. This actually brings me to an owl design question I immediately ran into. Until the point of applying a reasoner, it is not supposed to matter whether referenced ontologies are resolvable or not, but with Protege4 I found it easier to import the third party ontologies that I wanted to reference. Protege 4 resolves imports if the URI is a URL to some RDF. This made it easier for me to see how MRTG issues should relate to, e.g. dc issues in my desire to capture the informally stated relationships we put in the MRTG normative document (i.e. vocabularies in http://www.keytonature.eu/wiki/MRTG_Schema_v0.7) I am still left with the following design question:
Loosely, the question is: to capture an intent to re-use something like dc, should an ontology locally retarget the original property by restricting its domain, or should it define a new property and declare it to be owl:equivalentProperty to the original. For example, MRTG has an Identifier attribute of a MediaResource that is supposed to uniquely identify the resource.
One possibility is
<owl:DatatypeProperty rdf:about="dcterms:identifier"> <rdfs:domain rdf:resource="#MediaResource"/> </owl:DatatypeProperty>
This would let MRTG instance documents really reference dcterms:identifier and sidestep any mapping requirements in integration with resources already described by dc. It would also prohibit a MRTG valid description of a MediaResource have no other use of dcterms:identifier, which is probably a Good Thing for reasoning.
Another is (note upper case I in Identifier)
<owl:DatatypeProperty rdf:about="#Identifier"> <rdf:type rdf:resource="owl:FunctionalProperty"/> <owl:equivalentProperty rdf:resource=dcterms:identifier"/> <rdfs:domain rdf:resource="#MediaResource"/> <rdfs:range rdf:resource="xsd:anyURI"/> </owl:DatatypeProperty>
Is it easy to give a simple example of an axiom that would be consistent with one of these and inconsistent with another?
If in fact they are logically equivalent, is one of them better than the other on some other grounds?
Assume that dcterms is imported and resolved. Does the owl:equivalentProperty guarantee these two models must be logically equivalent?
For purposes of this question, ignore for the moment that dcterms:identifier actually has range xsd:Literal and is not declared a FunctionalProperty in the 2008 dcterms rdf. Also, pretend that it has the same range type that MRTG is after...a not entirely clear issue in itself...
Thanks
Bob p.s. I'm thinking that MRTG wiki needs some pages about modeling and representation and that questions like this belong there and/or on some related, more general, TDWG wiki... but which?
On Thu, May 14, 2009 at 8:37 AM, Roger Hyam rogerhyam@mac.com wrote:
Bob,
There is a difference between namespace re-use and importing of ontologies. When it comes to inference it depends on whether your inference engine goes off and pulls in the ontologies associated with the namespace or whether you override it in some way.
For good data provenance you need a crystal ball. Only after the event do you know what information should have been recorded in order to enable you to answer that all important question that has only now occurred to you. If we only knew how tall the photographer was we could ..... Which version of which software library compiled on which architecture was used to compress this image? Without a crystal ball you have to record everything just incase and I figure the law of diminishing returns kicks in pretty quickly.
Roger
On 12 May 2009, at 15:28, Bob Morris wrote:
Sometimes DC works and sometimes it doesn't. See http://www.keytonature.eu/wiki/MRTG_Schema_v0.7 where we spent and continue to spend a lot of effort to sort out (in the case of multimedia resources) what does and doesn't. I hope people will join that discussion. At the simplest level, what we do is use DC (and other standards) URI's for the URI of the term we are adopting. Some DC remains very vague and sloppy, even in the 2008 revision. The current "controversy" on the MRTG wiki is whether too much complexity gets introduced by trying to provide for data provenance. To me, this is an issue very important for science data, but only somewhat so in the communities classically served by DC---the cultural artifacts community possibly being the biggest exception.
Bob
On Tue, May 12, 2009 at 10:17 AM, Roderic Page r.page@bio.gla.ac.uk wrote: Dear Roger,
This is probably off topic (and maybe I missed something), but it really worries me that much of the TDWG vocabulary is unique to TDWG. Journal publishers are busy pumping out Dublin Core and PRISM (sometimes with FOAF). I'm trying to link this to records nomenclators pump out. I seem to recall some statement that where possible TDWG would reuse existing vocabularies, but I don't see this happening. In the meantime, I'm busy mapping our idiosyncratic vocabulary to that used by publishers.
Regards
Rod
On 12 May 2009, at 09:59, Roger Hyam wrote:
Hi All,
I need to do some work on the Taxon Name and Taxon Concept vocabularies and believe I have come up with a good way of organising the TDWG ontology space (everything within http:/ rs.tdwg.org/ontology).
The following are the changes I suggest:
All files should be OWL DL compliant All files should be openable in Protege 4 (I believe this is now good enough to use for editing these small ontologies) We take a highly structured modular approach I call this the Bricks and Mortar design pattern Some files are 'Bricks' and as such import or reference no other files, classes or individuals. e.g. TaxonName does not mention a higher 'Name' object in the class hierarchy. Other files are 'Mortar'. These files import Bricks and stipulate relationships between things. Because we are using OWL it is easy to define things like the class hierarchy or the range of a property in a separate file to the file the original class or property was defined in. This pattern gives us maximum re-usability as the same Brick could be used in different ways. It does not bind us to any one implementation of one object. An example of the usage pattern would be to define TaxonName, TaxonConcept, Rank, NomenclaturalCode as separate bricks that don't reference each other at all then create a TCS ontology that imports these 4 bricks and defines their relationships. We move to some other method of presenting the ontologies on line
- possibly the OWLDoc plug-in for Protege. This would lose us the
branded look we have at the moment but would be more flexible and consistent in the long run.
As I need to do this for the TaxonName TaxonConcept vocabularies I volunteer to do manage the space this year if people are happy going down this route.
From the point of view of deployed systems (the nomenclators) there may be a need for a namespace change on some properties but I would review what is in use and this would be trivial - if necessary at all.
What do you think? I will take silence as acquiescence on the grounds that any movement is better than none - though I don't suppose I will get round to doing anything about changes till after e-Biosphere in June.
All the best,
Roger
Roger Hyam - Project Officer WP4 Pan European Species Infrastructure
+44 75 90 60 80 16
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
-- Robert A. Morris Professor of Computer Science UMASS-Boston ram@cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/~ram/calendar.html phone (+1)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org
Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/
-- Robert A. Morris Professor of Computer Science UMASS-Boston ram@cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/~ram/calendar.html phone (+1)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
----------------------------------------------------- Roger Hyam - Project Officer WP4 Pan European Species Infrastructure +44 75 90 60 80 16 -----------------------------------------------------
Roger wrote:
The problem that I don't have a compelling answer to is: How do we tell people we would like them to tag their instances of MediaResource with dcterms:identifier without entailing anything in our ontology?
The only answer I have to this question is: Documentation and examples - which isn't sexy and compelling.
Oh yes it _is_!
I think a reasonable number of people are saying exactly this.
:) Ben
This email, together with any attachments, is intended for the addressee only. It may contain confidential or privileged information. If you are not the intended recipient of this email, please notify the sender, delete the email and attachments from your system and destroy any copies you may have taken of the email and its attachments. Duplication or further distribution by hardcopy, by electronic means or verbally is not permitted without permission.
participants (3)
-
Bob Morris -
Richardson, Ben -
Roger Hyam