Hi all,
I have a few nomenclatural relationships between name that I would like to express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'?
(2) Point an orthographic variant to the name which it is a variant of (whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too.
(3) Point a nomen nudum to a validly published instance that comes later (or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else.
Advice appreciated,
Regards - Tony Rees
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like to express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'?
yes, that is exactly right. As far as I understand the term basionym is more of a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of (whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too.
This is only possible with an extension I am afraid. For example the generic dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later (or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else.
same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
________________________________________ From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like to express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'?
yes, that is exactly right. As far as I understand the term basionym is more of a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of (whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too.
This is only possible with an extension I am afraid. For example the generic dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later (or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else.
same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Hmmm.... watch out for that tricky word "valid". It means different things to botanists & zoologists. The term "accepted" is generally seen as a more code-neutral term to mean "valid" (sensu zoology) or "correct"/"accepted" (sensu botany). But if you mean "valid" in the botanical sense (="validly published", or "available" sensu zoology). I'm not entirely sure which sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at TDWG seemed to have converged on the same idea that, perhaps, we should be using resourceRelationship more frequently (perhaps a *LOT* more frequently). A lot of these terms that effectively represent the functional equivalent to "foreign keys" might be better packaged in the more open-ended structure of resourceRelationship. In fact, at one of the sessions at TDWG (I believe it was at the AudubonCore break-out session), we discussed the idea of DwCA "2.0", which would essentially define n-number of "Cores", and then package the relationships among them via a set of resourceRelationship records. This idea emerged from a discussion about how people have been trying to "force" many-to-many sorts of data into the one-to-many DwCA format. The beauty of using a more generic resourceRelationship set for this function is that it allows one-to-one, one-to-many, and many-to-many relationships all in one structure. It may seem klunky now, but if we used it as a general method to describe all relationships between instances of DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha, Rich
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content- bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Tuesday, October 25, 2011 4:34 PM To: mdoering@gbif.org Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like
to
express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there
was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'? yes, that is exactly right. As far as I understand the term basionym is
more of
a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of
(whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too. This is only possible with an extension I am afraid. For example the
generic
dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later
(or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else. same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
Well sure, valid is overloaded just as accepted is which we nevertheless use for the "accepted" taxonomic relation. Leaving aside what the actual term name is, validNameUsage, correctNameUsage, amendedNameUsage or sth else - it seems to fix the problem, doesn't it?
"DwCa 2.0" would be a drastic change which feels like reinventing the relational wheel. It might be better to go with sth existing in that case, e.g. Google Dataset Publishing Language: http://code.google.com/apis/publicdata/
Using the generic relationship extension is good, but also has serious drawbacks. Immediately these come to my mind: - it is much harder to publish and consume data in this format. Without publishing tools you will be lost. - the controlled vocabulary for the relationship type must be *very* controlled. Especially we need to avoid overloading which will easily happen very quickly, see valid or accepted. - all linked resources must have unique ids across all classes, pretty much globally unique ids. Nice to have, but hard for publishers.
Markus
On 26.10.2011, at 00:58, Richard Pyle wrote:
Hmmm.... watch out for that tricky word "valid". It means different things to botanists & zoologists. The term "accepted" is generally seen as a more code-neutral term to mean "valid" (sensu zoology) or "correct"/"accepted" (sensu botany). But if you mean "valid" in the botanical sense (="validly published", or "available" sensu zoology). I'm not entirely sure which sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at TDWG seemed to have converged on the same idea that, perhaps, we should be using resourceRelationship more frequently (perhaps a *LOT* more frequently). A lot of these terms that effectively represent the functional equivalent to "foreign keys" might be better packaged in the more open-ended structure of resourceRelationship. In fact, at one of the sessions at TDWG (I believe it was at the AudubonCore break-out session), we discussed the idea of DwCA "2.0", which would essentially define n-number of "Cores", and then package the relationships among them via a set of resourceRelationship records. This idea emerged from a discussion about how people have been trying to "force" many-to-many sorts of data into the one-to-many DwCA format. The beauty of using a more generic resourceRelationship set for this function is that it allows one-to-one, one-to-many, and many-to-many relationships all in one structure. It may seem klunky now, but if we used it as a general method to describe all relationships between instances of DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha, Rich
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content- bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Tuesday, October 25, 2011 4:34 PM To: mdoering@gbif.org Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like
to
express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there
was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'? yes, that is exactly right. As far as I understand the term basionym is
more of
a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of
(whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too. This is only possible with an extension I am afraid. For example the
generic
dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later
(or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else. same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum. _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Hi Markus,
Well sure, valid is overloaded just as accepted is which we nevertheless
use
for the "accepted" taxonomic relation. Leaving aside what the actual term name is, validNameUsage, correctNameUsage, amendedNameUsage or sth else - it seems to fix the problem, doesn't it?
Perhaps, but I guess because of the ambiguity issue with "valid", I'm not completely sure which specific problem is being solved in this case. If, as from Tony's original email, it is to link a nomen nudum usage instance to its corresponding validly published/available usage instance, that makes some sense. But then do we need something similar for Emendations (e.g., emendedUsageInstance) and other sorts of nomenclatural relationships? How many of these "foreign keys" will we ultimately need? This is why I'm thinking in terms of something more relational.
"DwCa 2.0" would be a drastic change which feels like reinventing the relational wheel. It might be better to go with sth existing in that case,
e.g.
Google Dataset Publishing Language: http://code.google.com/apis/publicdata/
Yes, Tim just sent me that link off-list as well -- I'll take a look when I have some time.
Using the generic relationship extension is good, but also has serious drawbacks. Immediately these come to my mind:
- it is much harder to publish and consume data in this format. Without
publishing tools you will be lost.
- the controlled vocabulary for the relationship type must be *very*
controlled. Especially we need to avoid overloading which will easily
happen
very quickly, see valid or accepted.
- all linked resources must have unique ids across all classes, pretty
much
globally unique ids. Nice to have, but hard for publishers.
These are all valid points to be sure. However, I would like to think that many content providers are (gradually?) improving their ability to represent data in this more normalized way. I would also like to think that this trend is continuing. My sense from TDWG is that perhaps we're getting close to critical mass for enough providers, who have more robust needs for data exchange, to beign exploring more sophisticated ways of exchanging more rich datasets. If, indeed, this is the general trend, then it would be useful for a subset of providers with such capabilities and needs to begin exploring more robust implementations of dwc:resourceRelationship, including perhaps a CSV/Archive version modeled after DwCA. The BiSciCol project has been looking very closely at this sort of thing. It may not involve DwC (i.e., it may be framed in more semantic terms), but I still think there could be a need for a more fleshed-out definition and use case for resourceRelationship to meet the (growing?) list of providers who wish to express many-to-many relationships in a standardized way. Yes, we certainly would need a very carefully crafted controlled vocabulary for dwc:relationshipOfResource -- but I see that as a very worthwhile exercise in any case (especially as we move more and more towards semanic presentations of our content). Same can be said for persistent, actionable identifiers.
Aloha, Rich
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
Well sure, valid is overloaded just as accepted is which we nevertheless
use
for the "accepted" taxonomic relation. Leaving aside what the actual term name is, validNameUsage, correctNameUsage, amendedNameUsage or sth else - it seems to fix the problem, doesn't it?
Perhaps, but I guess because of the ambiguity issue with "valid", I'm not completely sure which specific problem is being solved in this case. If, as from Tony's original email, it is to link a nomen nudum usage instance to its corresponding validly published/available usage instance, that makes some sense. But then do we need something similar for Emendations (e.g., emendedUsageInstance) and other sorts of nomenclatural relationships? How many of these "foreign keys" will we ultimately need? This is why I'm thinking in terms of something more relational.
My hope would be that we only need one for a nomenclatural relationship and use the nom status to specify its exact meaning. But of course you could have multiple relations and then this method won't work. At least it would allow us to publish most of the data in a simple way before one has to step into the relationship extension.
Markus
Fair point. I guess I need to think about it some more.
-----Original Message----- From: "Markus Döring (GBIF)" [mailto:mdoering@gbif.org] Sent: Wednesday, October 26, 2011 11:40 AM To: Richard Pyle Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Well sure, valid is overloaded just as accepted is which we nevertheless
use
for the "accepted" taxonomic relation. Leaving aside what the actual term name is, validNameUsage, correctNameUsage, amendedNameUsage or sth else - it seems to fix the problem, doesn't it?
Perhaps, but I guess because of the ambiguity issue with "valid", I'm not completely sure which specific problem is being solved in this case. If, as from Tony's original email, it is to link a nomen nudum usage instance to its corresponding validly published/available usage instance, that makes some sense. But then do we need something similar for Emendations (e.g., emendedUsageInstance) and other sorts of nomenclatural relationships? How many of these "foreign keys" will we ultimately need? This is why I'm thinking in terms of something more relational.
My hope would be that we only need one for a nomenclatural relationship and use the nom status to specify its exact meaning. But of course you could have multiple relations and then this method won't work. At least it would allow us to publish most of the data in a simple way
before
one has to step into the relationship extension.
Markus
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
To your list of drawbacks, I would add one that has previously surfaced in this list: when there are multiple uses in the same record, the usage patterns may require advance agreement about how to disambiguate them. For example, what is to be made of a set of assertions that two different name URI's are both asserted to be that of an "accepted" name? Is that the two URI's reference the same thing? Is it that the record set contains an inconsistency? Is that the issue must be resolved by URI resolution , thereby introducing a requirement for resolvability) . These decisions may be very specific to the relation, and may make mapping between different community's relations quite complex.
On Wed, Oct 26, 2011 at 6:14 AM, "Markus Döring (GBIF)" mdoering@gbif.org wrote:
Well sure, valid is overloaded just as accepted is which we nevertheless use for the "accepted" taxonomic relation. Leaving aside what the actual term name is, validNameUsage, correctNameUsage, amendedNameUsage or sth else - it seems to fix the problem, doesn't it?
"DwCa 2.0" would be a drastic change which feels like reinventing the relational wheel. It might be better to go with sth existing in that case, e.g. Google Dataset Publishing Language: http://code.google.com/apis/publicdata/
Using the generic relationship extension is good, but also has serious drawbacks. Immediately these come to my mind: - it is much harder to publish and consume data in this format. Without publishing tools you will be lost. - the controlled vocabulary for the relationship type must be *very* controlled. Especially we need to avoid overloading which will easily happen very quickly, see valid or accepted.
- all linked resources must have unique ids across all classes, pretty much globally unique ids. Nice to have, but hard for publishers.
Markus
On 26.10.2011, at 00:58, Richard Pyle wrote:
Hmmm.... watch out for that tricky word "valid". It means different things to botanists & zoologists. The term "accepted" is generally seen as a more code-neutral term to mean "valid" (sensu zoology) or "correct"/"accepted" (sensu botany). But if you mean "valid" in the botanical sense (="validly published", or "available" sensu zoology). I'm not entirely sure which sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at TDWG seemed to have converged on the same idea that, perhaps, we should be using resourceRelationship more frequently (perhaps a *LOT* more frequently). A lot of these terms that effectively represent the functional equivalent to "foreign keys" might be better packaged in the more open-ended structure of resourceRelationship. In fact, at one of the sessions at TDWG (I believe it was at the AudubonCore break-out session), we discussed the idea of DwCA "2.0", which would essentially define n-number of "Cores", and then package the relationships among them via a set of resourceRelationship records. This idea emerged from a discussion about how people have been trying to "force" many-to-many sorts of data into the one-to-many DwCA format. The beauty of using a more generic resourceRelationship set for this function is that it allows one-to-one, one-to-many, and many-to-many relationships all in one structure. It may seem klunky now, but if we used it as a general method to describe all relationships between instances of DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha, Rich
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content- bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Tuesday, October 25, 2011 4:34 PM To: mdoering@gbif.org Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like
to
express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there
was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'? yes, that is exactly right. As far as I understand the term basionym is
more of
a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of
(whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too. This is only possible with an extension I am afraid. For example the
generic
dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later
(or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else. same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum. _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
We already have MANY ways to present bad data content, so this is just continuing an existing reality. At several conversations at TDWG (BiSciCol, RDF), came up the issue of how strongly to impose ontological rules to provided content. Having a robust ontology that met the needs of most use cases would be wonderful, of course. But failing that, an alternative is to let early-adopter content providers provide what they want (or think is right to provide), and then analyze this content to find where such illogical/impossible/circular/etc. content emerges.
At one of the RDF sessions, the example was shown of:
http://fu.bar hasIdentification rabbit
I presume this means a literal "rabbit" (a text string) -- which is entirely reasonable to expect some providers to provide. But others would provide something like:
http://fu.bar hasIdentification http://nameprovider.org/1234
...where the latter resolves to some metadata-rich object that includes among many of its properties the text-string "rabbit". But yet other providers may represent something like this:
http://fu.bar hasIdentification http://someorganization.org/identification/5678
...where the latter resolves to some metadata-rich object along the lines of the DwC Identification class, which includes among its properties a link to a particular instance along the lines of the DwC Taxon class, which itself has many properties, among which is the text literal "rabbit".
In any case, that people will expose irrational data is not, in itself, a reason to shy away from exploring more robust data exchange mechanisms in the context of TDWG standards.
Aloha, Rich
-----Original Message----- From: Bob Morris [mailto:morris.bob@gmail.com] Sent: Wednesday, October 26, 2011 11:33 AM To: Markus Döring (GBIF) Cc: Richard Pyle; tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
To your list of drawbacks, I would add one that has previously surfaced in
this
list: when there are multiple uses in the same record, the usage patterns may require advance agreement about how to disambiguate them. For example, what is to be made of a set of assertions that two different name URI's are both asserted to be that of an "accepted" name? Is that the two URI's reference the same thing? Is it that the record set contains an inconsistency? Is that the issue
must be
resolved by URI resolution , thereby introducing a requirement for resolvability) . These decisions may be very specific to the relation, and
may
make mapping between different community's relations quite complex.
On Wed, Oct 26, 2011 at 6:14 AM, "Markus Döring (GBIF)" mdoering@gbif.org wrote:
Well sure, valid is overloaded just as accepted is which we nevertheless
use
for the "accepted" taxonomic relation.
Leaving aside what the actual term name is, validNameUsage,
correctNameUsage, amendedNameUsage or sth else - it seems to fix the problem, doesn't it?
"DwCa 2.0" would be a drastic change which feels like reinventing the relational wheel. It might be better to go with sth existing in that case, e.g. Google Dataset Publishing Language: http://code.google.com/apis/publicdata/
Using the generic relationship extension is good, but also has serious
drawbacks. Immediately these come to my mind:
- it is much harder to publish and consume data in this format. Without
publishing tools you will be lost.
- the controlled vocabulary for the relationship type must be *very*
controlled. Especially we need to avoid overloading which will easily
happen
very quickly, see valid or accepted.
- all linked resources must have unique ids across all classes, pretty
much
globally unique ids. Nice to have, but hard for publishers.
Markus
On 26.10.2011, at 00:58, Richard Pyle wrote:
Hmmm.... watch out for that tricky word "valid". It means different things to botanists & zoologists. The term "accepted" is generally seen as a more code-neutral term to mean "valid" (sensu zoology) or
"correct"/"accepted"
(sensu botany). But if you mean "valid" in the botanical sense (="validly published", or "available" sensu zoology). I'm not entirely sure which sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at TDWG seemed to have converged on the same idea that, perhaps, we should be using resourceRelationship more frequently (perhaps a *LOT* more frequently). A lot of these terms that effectively represent the functional equivalent to "foreign keys" might be better packaged in the more open-ended structure of resourceRelationship. In fact, at one of the sessions at TDWG (I believe it was at the AudubonCore break-out session), we discussed the idea of DwCA "2.0", which would essentially define n-number of "Cores", and then package the relationships among them via a set of resourceRelationship records. This idea emerged from a discussion about how people have been trying to "force" many-to-many sorts of data into the one-to-many DwCA format. The beauty of using a more generic resourceRelationship set for this function is that it allows one-to-one, one-to-many, and many-to-many relationships all in one structure. It may seem klunky now, but if we used it as a general
method
to describe all relationships between instances of DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha, Rich
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content- bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Tuesday, October 25, 2011 4:34 PM To: mdoering@gbif.org Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship
extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like
to
express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there
was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one
quesiton
is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'? yes, that is exactly right. As far as I understand the term basionym is
more of
a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of
(whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too. This is only possible with an extension I am afraid. For example the
generic
dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later
(or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of
something else.
same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship
extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
This message is only intended for the addressee named above. Its
contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If
you
have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed
in
this message do not necessarily represent the views of the Bishop Museum.
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
-- Robert A. Morris
Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 IT Staff Filtered Push Project Department of Organismal and Evolutionary Biology Harvard University
email: morris.bob@gmail.com web: http://efg.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram phone (+1) 857 222 7992 (mobile)
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
The question I would ask in this example is what's the specific definition/circumscription of the predicate "hasIdentification"? Lacking any boundaries around the predicate, then you can have three uses of it that all have different meanings as shown in this case. Likewise given the breadth of English synonymy, multiple predicates can be concocted by different people that mean the same thing: isBasedOn, isSourcedFrom, isAccordingTo. Maybe we need just as much standardization of predicates as objects. DwC-Predicate?
Chuck
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: Wednesday, October 26, 2011 5:49 AM To: 'Bob Morris'; 'Markus Döring (GBIF)' Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
We already have MANY ways to present bad data content, so this is just continuing an existing reality. At several conversations at TDWG (BiSciCol, RDF), came up the issue of how strongly to impose ontological rules to provided content. Having a robust ontology that met the needs of most use cases would be wonderful, of course. But failing that, an alternative is to let early-adopter content providers provide what they want (or think is right to provide), and then analyze this content to find where such illogical/impossible/circular/etc. content emerges.
At one of the RDF sessions, the example was shown of:
http://fu.bar hasIdentification rabbit
I presume this means a literal "rabbit" (a text string) -- which is entirely reasonable to expect some providers to provide. But others would provide something like:
http://fu.bar hasIdentification http://nameprovider.org/1234
...where the latter resolves to some metadata-rich object that includes among many of its properties the text-string "rabbit". But yet other providers may represent something like this:
http://fu.bar hasIdentification http://someorganization.org/identification/5678
...where the latter resolves to some metadata-rich object along the lines of the DwC Identification class, which includes among its properties a link to a particular instance along the lines of the DwC Taxon class, which itself has many properties, among which is the text literal "rabbit".
In any case, that people will expose irrational data is not, in itself, a reason to shy away from exploring more robust data exchange mechanisms in the context of TDWG standards.
Aloha, Rich
-----Original Message----- From: Bob Morris [mailto:morris.bob@gmail.com] Sent: Wednesday, October 26, 2011 11:33 AM To: Markus Döring (GBIF) Cc: Richard Pyle; tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
To your list of drawbacks, I would add one that has previously surfaced in
this
list: when there are multiple uses in the same record, the usage patterns may require advance agreement about how to disambiguate them. For example, what is to be made of a set of assertions that two different name URI's are both asserted to be that of an "accepted" name? Is that the two URI's reference the same thing? Is it that the record set contains an inconsistency? Is that the issue
must be
resolved by URI resolution , thereby introducing a requirement for resolvability) . These decisions may be very specific to the relation, and
may
make mapping between different community's relations quite complex.
On Wed, Oct 26, 2011 at 6:14 AM, "Markus Döring (GBIF)" mdoering@gbif.org wrote:
Well sure, valid is overloaded just as accepted is which we nevertheless
use
for the "accepted" taxonomic relation.
Leaving aside what the actual term name is, validNameUsage,
correctNameUsage, amendedNameUsage or sth else - it seems to fix the problem, doesn't it?
"DwCa 2.0" would be a drastic change which feels like reinventing the relational wheel. It might be better to go with sth existing in that case, e.g. Google Dataset Publishing Language: http://code.google.com/apis/publicdata/
Using the generic relationship extension is good, but also has serious
drawbacks. Immediately these come to my mind:
- it is much harder to publish and consume data in this format.
Without
publishing tools you will be lost.
- the controlled vocabulary for the relationship type must be
*very*
controlled. Especially we need to avoid overloading which will easily
happen
very quickly, see valid or accepted.
- all linked resources must have unique ids across all classes,
pretty
much
globally unique ids. Nice to have, but hard for publishers.
Markus
On 26.10.2011, at 00:58, Richard Pyle wrote:
Hmmm.... watch out for that tricky word "valid". It means different things to botanists & zoologists. The term "accepted" is generally seen as a more code-neutral term to mean "valid" (sensu zoology) or
"correct"/"accepted"
(sensu botany). But if you mean "valid" in the botanical sense (="validly published", or "available" sensu zoology). I'm not entirely sure which sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at TDWG seemed to have converged on the same idea that, perhaps, we should be using resourceRelationship more frequently (perhaps a *LOT* more frequently). A lot of these terms that effectively represent the functional equivalent to "foreign keys" might be better packaged in the more open-ended structure of resourceRelationship. In fact, at one of the sessions at TDWG (I believe it was at the AudubonCore break-out session), we discussed the idea of DwCA "2.0", which would essentially define n-number of "Cores", and then package the relationships among them via a set of resourceRelationship records. This idea emerged from a discussion about how people have been trying to "force" many-to-many sorts of data into the one-to-many DwCA format. The beauty of using a more generic resourceRelationship set for this function is that it allows one-to-one, one-to-many, and many-to-many relationships all in one structure. It may seem klunky now, but if we used it as a general
method
to describe all relationships between instances of DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha, Rich
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content- bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Tuesday, October 25, 2011 4:34 PM To: mdoering@gbif.org Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship
extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like
to
express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there
was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one
quesiton
is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'? yes, that is exactly right. As far as I understand the term basionym is
more of
a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of
(whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too. This is only possible with an extension I am afraid. For example the
generic
dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later
(or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of
something else.
same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship
extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
This message is only intended for the addressee named above. Its
contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If
you
have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed
in
this message do not necessarily represent the views of the Bishop Museum.
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
-- Robert A. Morris
Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 IT Staff Filtered Push Project Department of Organismal and Evolutionary Biology Harvard University
email: morris.bob@gmail.com web: http://efg.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram phone (+1) 857 222 7992 (mobile)
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum. _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
I'm interested to see that the subject of the dwc:ResourceRelationship class has come up again. I have lost track of the number of times I've asked this question (I think it's somewhere around 4 times now) on the list without an answer: can anyone show me a functioning example where somebody is actually using the ResourceRelationship terms in any form? I have previously concluded from lack of response that there isn't actually anybody who has used them, but I would be happy to for someone to show that I'm wrong.
If I am understanding the use of the ResourceRelationship terms correctly (which I'm not at all sure about), dwc:resourceID represents an identifier for the subject of the relationship, dwc:relatedResourceID represents an identifier for the object of the relationship, and resourceRelationshipID represents an identifier for an _instance_ of a relationship which is further elaborated in the record for that instance by providing a string value for relationshipOfResource (using a controlled vocabulary) along with additional information about the relationships (according to whom, date, remarks). What I think I'm hearing in this thread is a desire to start using these terms more widely and to improve interoperability by standardizing the vocabulary used for relationshipOfResource. I also think I'm hearing that it would be a good idea for values the xxID terms to be GUIDs.
So what I'm wondering is why doing that would be better than just creating URI-identified object properties (a.k.a. predicates) that describe the relationship between the object and subject? Using the ResourceRelationship terms just makes "understanding" the relationship harder by requiring that the data consumer "look up" the value of the relationshipOfResource string for every instance of a relationship and then figure out if it's the same kind of relationship as one that the consumer already knows or cares about. As I see it, the bottom line is that if we agree that it would be a best-practice for the xxID values to be GUIDs (which would either be URIs or could be URIs that are proxied UUIDs for UUID believers) and that the relationships should be standardized, then the resource relationships boil down to RDF triples. There's a URI for the subject, a URI for the object, and there could be a URI for the relationshipOfResource which would have an rdfs:label property that was the controlled value for the string that describes the relationship. The only difference that I see is that the RDF triples could be more efficient to handle.
Don't like RDF or are scared of it? Fine, make yourself an Excel spreadsheet with three columns headed "subject", "predicate", and "object" (or use your favorite database method). Put the appropriate URI in each column. Viola! Resource relationships.
The one thing about implementing the ResourceRelationship class vocabulary that I think may be an improvement is use of the generic terms for "by whom", "date", and "remarks". At the present moment, we are in the process of expanding DwC by adding class-specific terms to do these things in nearly every class. We have recordedBy, georeferencedBy, identifiedBy, occurrenceRemarks, locationRemarks, eventDate, georeferencedDate, etc. rather than just using relationshipAccordingTo, relationshipEstablishedDate, and relationshipRemarks which could do the same thing generically in any class. Add columns to the above-described Excel spreadsheet for relationshipAccordingTo, relationshipEstablishedDate, and relationshipRemarks if you want to track those things.
I think I understand why the ResourceRelationship class was created. It seems like a way to move forward under the worse-case scenario where GUIDs never get off the ground, where no one ever agrees what the core biodiversity classes are, and where no one ever establishes object properties that connect those classes. But if no one ever has the guts to try to lay out the core classes and object properties that connect them, then what good are a million unstandardized ResourceRelationship instances that can't be unambiguously IDed? Nobody will ever be able to figure out anything useful from them and Rod Page's prophecy of doom will come true.
Somebody please show me where I'm wrong here... Steve
Richard Pyle wrote:
Hmmm.... watch out for that tricky word "valid". It means different things to botanists & zoologists. The term "accepted" is generally seen as a more code-neutral term to mean "valid" (sensu zoology) or "correct"/"accepted" (sensu botany). But if you mean "valid" in the botanical sense (="validly published", or "available" sensu zoology). I'm not entirely sure which sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at TDWG seemed to have converged on the same idea that, perhaps, we should be using resourceRelationship more frequently (perhaps a *LOT* more frequently). A lot of these terms that effectively represent the functional equivalent to "foreign keys" might be better packaged in the more open-ended structure of resourceRelationship. In fact, at one of the sessions at TDWG (I believe it was at the AudubonCore break-out session), we discussed the idea of DwCA "2.0", which would essentially define n-number of "Cores", and then package the relationships among them via a set of resourceRelationship records. This idea emerged from a discussion about how people have been trying to "force" many-to-many sorts of data into the one-to-many DwCA format. The beauty of using a more generic resourceRelationship set for this function is that it allows one-to-one, one-to-many, and many-to-many relationships all in one structure. It may seem klunky now, but if we used it as a general method to describe all relationships between instances of DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha, Rich
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content- bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Tuesday, October 25, 2011 4:34 PM To: mdoering@gbif.org Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like
to
express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there
was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'? yes, that is exactly right. As far as I understand the term basionym is
more of
a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of
(whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too. This is only possible with an extension I am afraid. For example the
generic
dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later
(or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else. same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum. _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
.
I have lost track of the number of times I've asked this question (I think it's somewhere around 4 times now) on the list without an answer: can anyone show me a functioning example where somebody is actually using the ResourceRelationship terms in any form?
That makes two of us.
If I am understanding the use of the ResourceRelationship terms correctly (which I'm not at all sure about), dwc:resourceID represents an identifier for the subject of the relationship, dwc:relatedResourceID represents an identifier for the object of the relationship, and resourceRelationshipID represents an identifier for an _instance_ of a relationship which is further elaborated in the record for that instance by providing a string value for relationshipOfResource (using a controlled
vocabulary) along with additional information about the relationships (according to whom, date, remarks). What I think I'm hearing in this thread is a desire to start using these terms more widely and to improve interoperability by standardizing the vocabulary used for
relationshipOfResource.
I also think I'm hearing that it would be a good idea for values the xxID
terms to be GUIDs.
That's *exactly* my perspective.
So what I'm wondering is why doing that would be better than just creating URI-identified object properties (a.k.a. predicates) that describe the relationship between the object and subject? Using the ResourceRelationship terms just makes "understanding" the relationship harder by requiring that the data consumer "look up" the value of the relationshipOfResource string for every instance of a relationship and then figure out if it's the same kind of
relationship
as one that the consumer already knows or cares about.
Hmmm... not sure I follow. My understanding is that resourceRelationship is just a DwC wrapper to exchange what effectively amounts to triples, but with some additional properties tied to each triple. In other words, a generalized way of packaging any kind of relationship (1:1, 1:M, M:M) in a format that is more in keeping with the way DwC works than RDF is. Perhaps we should just focus on RDF/triples and not bother with a DwC package for these kinds of relationships.
In any case, I don't see why relationshipOfResource cannot be populated with a URI-identified predicate. Or, perhaps introduce a relationshipOfResourceID term.
A suggestion was made by John Deck within BiSciCol to propose two new terms for this class: resourceType and relatedResourceType, which would be populated by the name of the DwC class from which the respective two identifiers are drawn. This would include the kinds of things being related without needing to resolve the two identifiers to determine that (e.g., via dcterms:type from each record). Whether or not BiSciCol utilizes this DwC class, I think it's still worth exploring and putting some use cases out there to test its efficacy.
As I see it, the bottom line is that if we agree that it would be a best-practice for the xxID values to be GUIDs (which would either be URIs or could be URIs that are proxied UUIDs for UUID believers)
I am a "UUID believer" (or, more correctly, a believer in 128-bit identifiers, of which UUID is merely one -- of potentially many -- protocol for generation and a convention for rendering that is more human-friendly than 128 consecutives 1's & 0's), and I am perfectly happy representing them in this context as URIs. I don't even think of it as a proxy anymore -- I think of it as a combined identifier (UUID) and resolution metadata (http or other protocol prefix with domain+namespace), such that they fulfill the function of a persistent, actionable identifier sensu TDWG.
But I digress...
and that the relationships should be standardized, then the resource relationships boil down to RDF triples.
Effectively, yes. But as I mentioned above, there may be value in defining a DwC mechanism (indeed, it's already defined, just not really used -- so I should have said "refining" instead of "defining") that allows packaging of these "triples" with associated metadata (relationshipAccordingTo, relationshipEstablishedDate, relationshipRemarks, and possibly resourceType and relatedResourceType) in a package that's easier for many providers to generate and digest than full-blown serialized RDF. Perhaps I'm way off base here, but my discussions at TDWG gave me the sense that I'm not the only one who sees this as a desirable mechanism for data exchange that has its own space of utility separate from full RDF-serialized content. My sense (and again, I may be way off base) is that the RDF becomes really valuable when it is broadly implemented, and is working off a reasonably functional and well-defined ontology. The day when those are reality will certainly come (I hope!), but in the mean time, we still need an exchange mechanism for certain content that is more complex than what can be met with DwCA.
There's a URI for the subject, a URI for the object, and there could be a URI for the relationshipOfResource which would have an rdfs:label property that was the controlled value for the string that describes the relationship.
I am fully supportive of this.
The only difference that I see is that the RDF triples could be more efficient to handle.
...or more difficult to handle, depending on who you are, what your area of technical expertise is, and what you want to use the standard for (e.g., content exchange vs. reasoning).
Don't like RDF or are scared of it? Fine, make yourself an Excel spreadsheet with three columns headed "subject", "predicate", and "object" (or use your favorite database method). Put the appropriate URI in each column. Viola! Resource relationships.
Great! Add in columns for relationshipAccordingTo, relationshipEstablishedDate, relationshipRemarks, resourceType and relatedResourceType (would that be septuples?), so I don't have to serialize these standard properties of the relationships into additional triples, and I'm sold!
Aloha, Rich
The one thing about implementing the ResourceRelationship class vocabulary that I think may be an improvement is use of the generic terms for "by whom", "date", and "remarks". At the present moment, we are in the process of expanding DwC by adding class-specific terms to do these things in nearly every class. We have recordedBy, georeferencedBy, identifiedBy, occurrenceRemarks, locationRemarks, eventDate, georeferencedDate, etc. rather than just using relationshipAccordingTo, relationshipEstablishedDate, and relationshipRemarks which could do the same thing generically in any class. Add columns to the above-described Excel spreadsheet for relationshipAccordingTo, relationshipEstablishedDate, and relationshipRemarks if you want to track those things.
I think I understand why the ResourceRelationship class was created. It seems like a way to move forward under the worse-case scenario where GUIDs never get off the ground, where no one ever agrees what the core biodiversity classes are, and where no one ever establishes object properties that connect those classes. But if no one ever has the guts to try to lay out the core classes and object properties that connect them, then what good are a million unstandardized ResourceRelationship instances that can't be unambiguously IDed? Nobody will ever be able to figure out anything useful from them and Rod Page's prophecy of doom will come true.
Somebody please show me where I'm wrong here... Steve
Richard Pyle wrote: Hmmm.... watch out for that tricky word "valid". It means different things to botanists & zoologists. The term "accepted" is generally seen as a more code-neutral term to mean "valid" (sensu zoology) or "correct"/"accepted" (sensu botany). But if you mean "valid" in the botanical sense (="validly published", or "available" sensu zoology). I'm not entirely sure which sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at TDWG seemed to have converged on the same idea that, perhaps, we should be using resourceRelationship more frequently (perhaps a *LOT* more frequently). A lot of these terms that effectively represent the functional equivalent to "foreign keys" might be better packaged in the more open-ended structure of resourceRelationship. In fact, at one of the sessions at TDWG (I believe it was at the AudubonCore break-out session), we discussed the idea of DwCA "2.0", which would essentially define n-number of "Cores", and then package the relationships among them via a set of resourceRelationship records. This idea emerged from a discussion about how people have been trying to "force" many-to-many sorts of data into the one-to-many DwCA format. The beauty of using a more generic resourceRelationship set for this function is that it allows one-to-one, one-to-many, and many-to-many relationships all in one structure. It may seem klunky now, but if we used it as a general method to describe all relationships between instances of DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha, Rich
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content- bounces@lists.tdwg.org] On Behalf Of Tony.Rees@csiro.au Sent: Tuesday, October 25, 2011 4:34 PM To: mdoering@gbif.org Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Yes, I believe this would cover both the cases I need, I think, when accompanied by nomenclatural status = misspelling / nomenclatural status = nomen nudum... - comments, anyone?
Cheers - Tony
________________________________________ From: "Markus Döring (GBIF)" [mdoering@gbif.org] Sent: Wednesday, 26 October 2011 1:43 AM To: Rees, Tony (CMAR, Hobart) Cc: tdwg-content@lists.tdwg.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony, thanks for these practical questions. See inline for answers. Markus
I have a few nomenclatural relationships between name that I would like
to
express using DwC, and would like to know the preferred way to do this if any. The relationships are as follows:
(1) Point a nomen novum to the basionym it replaces. From reading there
was formerly a concept basionym/basionymID, apparently this is now replaced with originalNameUsage/originalNameUsageID. So one quesiton is, is this sufficient to infer this is a basionym, when accompanied by noneclaturalStatus = 'nomen novum'? yes, that is exactly right. As far as I understand the term basionym is
more of
a botanical term and was not used as the final dwc term therefore.
(2) Point an orthographic variant to the name which it is a variant of
(whether or not the latter is now the accepted name). In other words, if name A is a variant of name B which is now a synonym of name C, I capture the A=>C relationship with a synonym assertion, but I want a way to capteure the A=>B relationship too. This is only possible with an extension I am afraid. For example the
generic
dwc relationship one: http://rs.gbif.org/extension/dwc/resource_relation.xml
(3) Point a nomen nudum to a validly published instance that comes later
(or do the same in reverse, i.e. this name was preceded by xxx as a nomen nudum). Again, this should be independent of whether the validly published name is an accepted name or now a synonym of something else. same problem as above. I begin to wonder if a new term dwc:validNameUsageID would solve this issue gracefully and remove the need for a relationship extension.
Advice appreciated,
Regards - Tony Rees _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
_______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum. _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
.
-- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences
postal mail address: VU Station B 351634 Nashville, TN 37235-1634, U.S.A.
delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235
office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 343-6707 http://bioimages.vanderbilt.edu
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
Richard Pyle wrote:
Hmmm... not sure I follow. My understanding is that resourceRelationship is just a DwC wrapper to exchange what effectively amounts to triples, but with some additional properties tied to each triple. In other words, a generalized way of packaging any kind of relationship (1:1, 1:M, M:M) in a format that is more in keeping with the way DwC works than RDF is. Perhaps we should just focus on RDF/triples and not bother with a DwC package for these kinds of relationships.
Well, I guess one could make the case that people who are not interested in RDF might want a DwC-only way to express this. I guess my point was that we seem to be talking about trying to invent a method to accomplish something where there already is a well-established way to do it. DwC at the present has a very "flat" database orientation and I think the resource-relationship terms were introduced to allow for a "flat" way to describe resources that aren't really flat (i.e. 1:M or M:M).
In any case, I don't see why relationshipOfResource cannot be populated with a URI-identified predicate. Or, perhaps introduce a relationshipOfResourceID term.
It's based on the term definition and examples at http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource which recommend a controlled vocabulary and give strings as the only examples. I think that in keeping with other precedents in DwC your suggestion of "relationshipOfResourceID" might be better.
A suggestion was made by John Deck within BiSciCol to propose two new terms for this class: resourceType and relatedResourceType, which would be populated by the name of the DwC class from which the respective two identifiers are drawn. This would include the kinds of things being related without needing to resolve the two identifiers to determine that (e.g., via dcterms:type from each record). Whether or not BiSciCol utilizes this DwC class, I think it's still worth exploring and putting some use cases out there to test its efficacy.
Well, in terms of the type for the subject, I don't think there is any reason to create a new term for that. There is already rdf:type to do exactly that. Whether it would matter if DwC imports that term or not, I don't know. It is certainly already "well known". relatedResourceType could be a shortcut to accomplish what you want for the object. We are still left with the problem that there is no consensus about what are the core "types" (which I consider to be equivalent to the question of what are the core classes) in our community. I've argued for adopting the DwC classes where they will do the job, but I haven't heard too many people express support for that and there are necessary classes that don't exist (yet) within DwC (e.g. a class for agents). Also, there are classes in the TDWG ontology that may or may not overlap with DwC classes (most notably dwc:Taxon). Do we use therm? So in order for this to be of much value, it seems to me that there is a need to hash out the core classes/types. I was hoping the RDF group would take that up, but it's not clear to me that there is support for doing that at this stage (was it discussed at the meeting?).
and that the relationships should be standardized, then the resource relationships boil down to RDF triples.
Effectively, yes. But as I mentioned above, there may be value in defining a DwC mechanism (indeed, it's already defined, just not really used -- so I should have said "refining" instead of "defining") that allows packaging of these "triples" with associated metadata (relationshipAccordingTo, relationshipEstablishedDate, relationshipRemarks, and possibly resourceType and relatedResourceType) in a package that's easier for many providers to generate and digest than full-blown serialized RDF. Perhaps I'm way off base here, but my discussions at TDWG gave me the sense that I'm not the only one who sees this as a desirable mechanism for data exchange that has its own space of utility separate from full RDF-serialized content. My sense (and again, I may be way off base) is that the RDF becomes really valuable when it is broadly implemented, and is working off a reasonably functional and well-defined ontology. The day when those are reality will certainly come (I hope!), but in the mean time, we still need an exchange mechanism for certain content that is more complex than what can be met with DwCA.
I agree. I don't see any reason why the same relationships that one can express in RDF triples couldn't be expressed in a database table. But some of the issues that must be addressed to make that work are (in my mind) the same ones that need to be addressed to make RDF work as a metadata transfer mechanism. They could probably both be worked out at the same time to some extent.
The only difference that I see is that the RDF triples could be more efficient to handle.
...or more difficult to handle, depending on who you are, what your area of technical expertise is, and what you want to use the standard for (e.g., content exchange vs. reasoning).
Well, I actually wasn't so much concerned with the mechanics of actually handling the RDF as the fact that it makes more sense to me to have a generic URI to describe a particular kind of resource relationship than to have to parse out and interpret a string for every relationship that is to be described. One of the points of RDF is that it doesn't have a single representation (e.g. it doesn't have to be represented as XML). But the subject, predicate, object relationship is basic and that's pretty much what we are talking about here.
Steve
Well, I guess one could make the case that people who are not interested in RDF might want a DwC-only way to express this.
Maybe "not interested" is not the best way to put it. Perhaps "not ready".
I guess my point was that we seem to be talking about trying to invent a method to accomplish something where there already is a well-established way to do it. DwC at the present has a very "flat" database orientation and I think the resource-relationship terms were introduced to allow for a "flat" way to describe resources that aren't really flat (i.e. 1:M or M:M).
Agreed. But resourceRelationship is already in there, and as we both seem to have discovered, nobody appears to be using it. So...I think we at least need to clarify how it's supposed to be used in a DwC context; or we should let it die a slow, quiet death of non-use. I guess I'm OK either way; but given that it exists, and given that we seem to have people who don't want to go all the way to RDF triples for all data exchange purposes (yet), perhaps we should examine how best to use this already-existing DwC class, modify it as needed to make it actually useful to those who want to use it, and let it die after we're all pumping our data out via RDF that works against a solid, stable ontology.
It's based on the term definition and examples at http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource which recommend a controlled vocabulary and give strings as the only
examples.
I think that in keeping with other precedents in DwC your suggestion of "relationshipOfResourceID" might be better.
Agreed.
Well, in terms of the type for the subject, I don't think there is any
reason to
create a new term for that. There is already rdf:type to do exactly
that.
Well...there's also dcterms:type, which is already part of DwC. The problem, though, that this would apply to resourceRelationshipID (i.e., the "type" of relationship itself); not to the resourceID. Technically, you'd need to resolve resourceID to retrieve dcterms:type for the subject item. I don't know how rdf:type is intended to work in this context.
Whether it would matter if DwC imports that term or not, I don't know.
How is it different from dcterms:type?
It is certainly already "well known". relatedResourceType could be a
shortcut
to accomplish what you want for the object. We are still left with the
problem
that there is no consensus about what are the core "types" (which I
consider
to be equivalent to the question of what are the core classes) in our
community.
I've argued for adopting the DwC classes where they will do the job, but I
haven't
heard too many people express support for that and there are necessary
classes
that don't exist (yet) within DwC (e.g. a class for agents).
Can't DwC simply import terms from foaf, like it does with dcterms?
Also, there are classes in the TDWG ontology that may or may not overlap
with
DwC classes (most notably dwc:Taxon). Do we use therm?
Perhaps. I guess it would depend on demand and specific use cases.
So in order for this to be of much value, it seems to me that there is a
need to
hash out the core classes/types. I was hoping the RDF group would take
that up,
but it's not clear to me that there is support for doing that at this
stage
(was it discussed at the meeting?).
Yes, it was discussed at the meeting -- at least in the BiSciCol group and the RDF group. There seemed to me a growing interest in resurrecting a discussion about a TDWG ontology, to see if it could be finished. Not in full-spec detail; but at least to the level of the DwC classes (and other like-level entities). I only caught part of the discussion at the RDF group, but Cam was there. It seemed to me that several people were citing the Darwin-SW ontology as a starting point (ahem....).
The day when those are reality will certainly come (I hope!), but in the mean time, we still need an
exchange
mechanism for certain content that is more complex than what can be met
with
DwCA.
I agree. I don't see any reason why the same relationships that one can
express in
RDF triples couldn't be expressed in a database table. But some of the
issues that
must be addressed to make that work are (in my mind) the same ones that
need
to be addressed to make RDF work as a metadata transfer mechanism. They could probably both be worked out at the same time to some extent.
Yes, agreed! They should absolutely be worked out at the same time.
Well, I actually wasn't so much concerned with the mechanics of actually handling the RDF as the fact that it makes more sense to me to have a generic URI to describe a particular kind of resource relationship than to
have to parse out and interpret a string for every relationship that is to be described. One of the points of RDF is that it doesn't have a single representation (e.g. it doesn't have to be represented as XML). But the subject, predicate, object relationship is basic and that's pretty
much what we are talking about here.
OK, I agree. It could be that resourceRelationship is a "gateway drug" to get people into thinking in terms of triples.
Rich
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
Richard Pyle wrote:
I guess my point was that we seem to be talking about trying to invent a method to accomplish something where there already is a well-established way to do it. DwC at the present has a very "flat" database orientation and I think the resource-relationship terms were introduced to allow for a "flat" way to describe resources that aren't really flat (i.e. 1:M or M:M).
Agreed. But resourceRelationship is already in there, and as we both seem to have discovered, nobody appears to be using it. So...I think we at least need to clarify how it's supposed to be used in a DwC context; or we should let it die a slow, quiet death of non-use. I guess I'm OK either way; but given that it exists, and given that we seem to have people who don't want to go all the way to RDF triples for all data exchange purposes (yet), perhaps we should examine how best to use this already-existing DwC class, modify it as needed to make it actually useful to those who want to use it, and let it die after we're all pumping our data out via RDF that works against a solid, stable ontology.
If one were able to establish an understanding of how to populate the seven or so "resource relationship" database columns that you want, converting that information to RDF in any or all of its forms would be an academic exercise. Somebody who knew what they were doing could probably write a program to do the conversion in less than an hour. That's not really the impediment.
Well, in terms of the type for the subject, I don't think there is any
reason to
create a new term for that. There is already rdf:type to do exactly
that.
Well...there's also dcterms:type, which is already part of DwC. The problem, though, that this would apply to resourceRelationshipID (i.e., the "type" of relationship itself); not to the resourceID. Technically, you'd need to resolve resourceID to retrieve dcterms:type for the subject item. I don't know how rdf:type is intended to work in this context.
There is probably somebody who is more qualified than me to address this, but I would say that because it is described as a part of RDF, rdf:type implicitly identifies the class of which the subject of a set of relationships is an instance. That is exactly what is wanted here. I think that in contrast dcterms:type means whatever you want it to mean as long as it fits the description of "The nature or genre of the resource." The best practice is to follow a controlled vocabulary, but otherwise I think people can use it to describe whatever they want. I may be in need of correction on this statement...
OK, I agree. It could be that resourceRelationship is a "gateway drug" to get people into thinking in terms of triples.
Now that brings up some interesting images in my brain! :-)
Steve
Rich
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
.
"perhaps we should examine how best to use this already-existing DwC class"
I'm thinking we need much more clarity for the TDWG community on this very point. What are the best uses of DwC terms?
Distinguishing the uses/methods/techniques from the DwC terms themselves would be very useful I think. In any particular discussion, it would be helpful if it were clear if the use in discussion was about using DwC in a Generic Darwin Core XML Schema, Simple Darwin Core XML Schema, or Darwin Core Text Schema (all defined in the Standard) or in a DwC-A package or an RDF triple structure or some other. Without structure or relationships, terms are just terms aren't they? Maybe I'm just uneducated in this area.
Chuck
-----Original Message----- From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: Wednesday, October 26, 2011 1:25 PM To: 'Steve Baskauf' Cc: tdwg-content@lists.tdwg.org; mdoering@gbif.org Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Well, I guess one could make the case that people who are not interested in RDF might want a DwC-only way to express this.
Maybe "not interested" is not the best way to put it. Perhaps "not ready".
I guess my point was that we seem to be talking about trying to invent
a method to accomplish something where there already is a well-established way to do it. DwC at the present has a very "flat" database orientation and I think the resource-relationship terms were introduced to allow for a "flat" way to describe resources that aren't
really flat (i.e. 1:M or M:M).
Agreed. But resourceRelationship is already in there, and as we both seem to have discovered, nobody appears to be using it. So...I think we at least need to clarify how it's supposed to be used in a DwC context; or we should let it die a slow, quiet death of non-use. I guess I'm OK either way; but given that it exists, and given that we seem to have people who don't want to go all the way to RDF triples for all data exchange purposes (yet), perhaps we should examine how best to use this already-existing DwC class, modify it as needed to make it actually useful to those who want to use it, and let it die after we're all pumping our data out via RDF that works against a solid, stable ontology.
It's based on the term definition and examples at http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource which recommend a controlled vocabulary and give strings as the only
examples.
I think that in keeping with other precedents in DwC your suggestion of "relationshipOfResourceID" might be better.
Agreed.
Well, in terms of the type for the subject, I don't think there is any
reason to
create a new term for that. There is already rdf:type to do exactly
that.
Well...there's also dcterms:type, which is already part of DwC. The problem, though, that this would apply to resourceRelationshipID (i.e., the "type" of relationship itself); not to the resourceID. Technically, you'd need to resolve resourceID to retrieve dcterms:type for the subject item. I don't know how rdf:type is intended to work in this context.
Whether it would matter if DwC imports that term or not, I don't know.
How is it different from dcterms:type?
It is certainly already "well known". relatedResourceType could be a
shortcut
to accomplish what you want for the object. We are still left with the
problem
that there is no consensus about what are the core "types" (which I
consider
to be equivalent to the question of what are the core classes) in our
community.
I've argued for adopting the DwC classes where they will do the job, but I
haven't
heard too many people express support for that and there are necessary
classes
that don't exist (yet) within DwC (e.g. a class for agents).
Can't DwC simply import terms from foaf, like it does with dcterms?
Also, there are classes in the TDWG ontology that may or may not overlap
with
DwC classes (most notably dwc:Taxon). Do we use therm?
Perhaps. I guess it would depend on demand and specific use cases.
So in order for this to be of much value, it seems to me that there is
a
need to
hash out the core classes/types. I was hoping the RDF group would take
that up,
but it's not clear to me that there is support for doing that at this
stage
(was it discussed at the meeting?).
Yes, it was discussed at the meeting -- at least in the BiSciCol group and the RDF group. There seemed to me a growing interest in resurrecting a discussion about a TDWG ontology, to see if it could be finished. Not in full-spec detail; but at least to the level of the DwC classes (and other like-level entities). I only caught part of the discussion at the RDF group, but Cam was there. It seemed to me that several people were citing the Darwin-SW ontology as a starting point (ahem....).
The day when those are reality will certainly come (I hope!), but in the mean time, we still need an
exchange
mechanism for certain content that is more complex than what can be met
with
DwCA.
I agree. I don't see any reason why the same relationships that one can
express in
RDF triples couldn't be expressed in a database table. But some of the
issues that
must be addressed to make that work are (in my mind) the same ones that
need
to be addressed to make RDF work as a metadata transfer mechanism. They could probably both be worked out at the same time to some
extent.
Yes, agreed! They should absolutely be worked out at the same time.
Well, I actually wasn't so much concerned with the mechanics of actually handling the RDF as the fact that it makes more sense to me to have a generic URI to describe a particular kind of resource relationship than to
have to parse out and interpret a string for every relationship that is to be described. One of the points of RDF is that it doesn't have a single representation (e.g. it doesn't have to be represented as
XML).
But the subject, predicate, object relationship is basic and that's pretty
much what we are talking about here.
OK, I agree. It could be that resourceRelationship is a "gateway drug" to get people into thinking in terms of triples.
Rich
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum. _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
participants (6)
-
"Markus Döring (GBIF)" -
Bob Morris -
Chuck Miller -
Richard Pyle -
Steve Baskauf -
Tony.Rees＠csiro.au