On Tue, Aug 24, 2010 at 6:24 AM, John Wieczorek tuco@berkeley.edu wrote:
Note that associatedOccurrences is one of the several terms that are meant to allow lists of relationships between resources to be captured in a single field. Others include associatedMedia, associatedReferences, associatedSequnces, and associatedTaxa. The main purposes of these fields is to provide a mechanism to share relationship information in a flat application profile such as the Simple Darwin Core (http://rs.tdwg.org/dwc/terms/simple/index.htm). If an application profile isn't constrained by being flat, then there is a much more robust way to capture relationships, using the ResourceRelationship class and it's constituent terms (http://rs.tdwg.org/dwc/terms/index.htm#relindex).
However, the values of the description of the relationship (http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource) are not controlled, so this still doesn't provide a "community-defined" vocabulary that Bob was asking about.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences
The term relationshipOfResource has the recommendation to use a controlled vocabulary. The vocabulary does not yet exist - it is an aspect that requires community development. The ResourceRelationship class has the added benefits over the associatedOccurrences term that there is no dependence on the syntax of the content to discern the correct meaning.
From http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource:
Definition: The relationship of the resource identified by relatedResourceID to the subject (optionally identified by the resourceID). Recommended best practice is to use a controlled vocabulary.
Comment: Examples: "duplicate of", "mother of", "endoparasite of", "host to", "sibling of", "valid synonym of", "located within". For discussion see http://code.google.com/p/darwincore/wiki/ResourceRelationship
On Tue, Aug 24, 2010 at 7:07 AM, Mark Wilden mark@mwilden.com wrote:
On Tue, Aug 24, 2010 at 6:24 AM, John Wieczorek tuco@berkeley.edu wrote:
Note that associatedOccurrences is one of the several terms that are
meant
to allow lists of relationships between resources to be captured in a
single
field. Others include associatedMedia, associatedReferences, associatedSequnces, and associatedTaxa. The main purposes of these fields
is
to provide a mechanism to share relationship information in a flat application profile such as the Simple Darwin Core (http://rs.tdwg.org/dwc/terms/simple/index.htm). If an application
profile
isn't constrained by being flat, then there is a much more robust way to capture relationships, using the ResourceRelationship class and it's constituent terms (http://rs.tdwg.org/dwc/terms/index.htm#relindex).
However, the values of the description of the relationship (http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource) are not controlled, so this still doesn't provide a "community-defined" vocabulary that Bob was asking about.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
On Tue, Aug 24, 2010 at 7:28 AM, John Wieczorek tuco@berkeley.edu wrote:
Recommended best practice is to use a controlled vocabulary.
This sounds like an incorrect usage of the term "best practice," to me. It can't be a "best practice" to do something that is impossible, and if a controlled vocabulary doesn't exist... As you indicate, this has a requirement that hasn't yet been met.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences
On Tue, Aug 24, 2010 at 9:20 AM, Mark Wilden mark@mwilden.com wrote:
On Tue, Aug 24, 2010 at 7:28 AM, John Wieczorek tuco@berkeley.edu wrote:
Recommended best practice is to use a controlled vocabulary.
This sounds like an incorrect usage of the term "best practice," to me. It can't be a "best practice" to do something that is impossible, and if a controlled vocabulary doesn't exist... As you indicate, this has a requirement that hasn't yet been met.
It is not a requirement, it is a recommendation. It is not impossible, just make a vocabulary. Well, hopefully with some community buy-in and open access. GBIF's vocabulary registry (http://vocabularies.gbif.org/) comes to mind as a solution.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
On Tue, Aug 24, 2010 at 9:29 AM, John Wieczorek tuco@berkeley.edu wrote:
On Tue, Aug 24, 2010 at 9:20 AM, Mark Wilden mark@mwilden.com wrote:
On Tue, Aug 24, 2010 at 7:28 AM, John Wieczorek tuco@berkeley.edu wrote:
Recommended best practice is to use a controlled vocabulary.
This sounds like an incorrect usage of the term "best practice," to me. It can't be a "best practice" to do something that is impossible, and if a controlled vocabulary doesn't exist... As you indicate, this has a requirement that hasn't yet been met.
It is not a requirement, it is a recommendation.
I meant "required" in the logical sense. If 50 different groups are each using their own vocabulary, it isn't really very controlled, in my view. In order for there to be a truly useful controlled vocabulary, it is required that everyone use the same one.
It is not impossible, just make a vocabulary. Well, hopefully with some community buy-in and open access. GBIF's vocabulary registry (http://vocabularies.gbif.org/) comes to mind as a solution.
That sounds good.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences
On Tue, Aug 24, 2010 at 9:37 AM, Mark Wilden mark@mwilden.com wrote:
On Tue, Aug 24, 2010 at 9:29 AM, John Wieczorek tuco@berkeley.edu wrote:
On Tue, Aug 24, 2010 at 9:20 AM, Mark Wilden mark@mwilden.com wrote:
On Tue, Aug 24, 2010 at 7:28 AM, John Wieczorek tuco@berkeley.edu
wrote:
Recommended best practice is to use a controlled vocabulary.
This sounds like an incorrect usage of the term "best practice," to me. It can't be a "best practice" to do something that is impossible, and if a controlled vocabulary doesn't exist... As you indicate, this has a requirement that hasn't yet been met.
It is not a requirement, it is a recommendation.
I meant "required" in the logical sense. If 50 different groups are each using their own vocabulary, it isn't really very controlled, in my view. In order for there to be a truly useful controlled vocabulary, it is required that everyone use the same one.
I'm sure I don't agree with this. I think it is extremely useful to take the first step by creating vocabularies within disciplines that make sense within that discipline. This approach allows for buy-in at a natural level of organization and understanding (not to mention activity), allows evolution, and can be resolved at the level of ontologies that synonymize between vocabularies when necessary.
It is not impossible, just
make a vocabulary. Well, hopefully with some community buy-in and open access. GBIF's vocabulary registry (http://vocabularies.gbif.org/) comes
to
mind as a solution.
That sounds good.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences
On Tue, Aug 24, 2010 at 9:47 AM, John Wieczorek tuco@berkeley.edu wrote:
I think it is extremely useful to take the first step by creating vocabularies within disciplines that make sense within that discipline.
Me too, but I said "group," not "discipline." If each domain (discipline) has its own controlled vocabulary, the union of these is indeed was Bob was looking for, I think. But if CAS has one vocabulary for its specimen date and AMNH has another, I don't call that very controlled. A useful first step, though.
This approach allows for buy-in at a natural level of organization and understanding (not to mention activity), allows evolution, and can be resolved at the level of ontologies that synonymize between vocabularies when necessary.
But I wonder if it's better to have each of those 50 groups (organizations) come up with its own vocabulary, then reconcile them, or instead have a meta-group like, oh, TDWG or GBIF, decide on one that makes sense.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences
if someone wants to start such a vocabulary by providing a first draft for relationship types Id be glad to add it to the recommended GBIF vocabularies: http://rs.gbif.org/vocabulary/
A simple list of term + definition would be enough. Maybe we can start to compile such a list within this thread?
Markus
PS: most of those vocabularies are derived from http://vocabularies.gbif.org/vocabularies We wanted a bit more stability though and curate rs.gbif.org in svn - but we are always open for moderated changes or additions.
PPS: the vocabularies hosted are in xml but we plan to expose them also as rdf at some point with the same URIs as listed. (probably only the ones using the gbif domain as we dont control the other domains)
On Aug 24, 2010, at 19:01, Mark Wilden wrote:
On Tue, Aug 24, 2010 at 9:47 AM, John Wieczorek tuco@berkeley.edu wrote:
I think it is extremely useful to take the first step by creating vocabularies within disciplines that make sense within that discipline.
Me too, but I said "group," not "discipline." If each domain (discipline) has its own controlled vocabulary, the union of these is indeed was Bob was looking for, I think. But if CAS has one vocabulary for its specimen date and AMNH has another, I don't call that very controlled. A useful first step, though.
This approach allows for buy-in at a natural level of organization and understanding (not to mention activity), allows evolution, and can be resolved at the level of ontologies that synonymize between vocabularies when necessary.
But I wonder if it's better to have each of those 50 groups (organizations) come up with its own vocabulary, then reconcile them, or instead have a meta-group like, oh, TDWG or GBIF, decide on one that makes sense.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
I'm on John's side on this, but it is not necessarily an easy path forward if you want the CVs to work with multiple technologies and tools. That remains a research problem that is addressed in more than one pending proposal to the U.S. NSF's SI2 program http://www.nsf.gov/pubs/2010/nsf10551/nsf10551.htm
As an example, while http://rs.tdwg.org/dwc/rdf/dwcterms.rdf will load on its own into Protege 4.1beta, and attempt to import it into an otherwise valid OWL ontology throws a NullPointerException. (This is probably a simple programming error, but in general, Protege4 has design propensities favoring actual OWL ontologies. The result is that even where dwc.rdf loads, the perfectly reasonable minimalist style of dwc.rdf causes all terms to appear as individuals instead of properties. That shouldn't impede their use in an OWL ontology, but the UI of Protege makes it unpleasant, if not impossible).
On Tue, Aug 24, 2010 at 12:29 PM, John Wieczorek tuco@berkeley.edu wrote:
On Tue, Aug 24, 2010 at 9:20 AM, Mark Wilden mark@mwilden.com wrote:
On Tue, Aug 24, 2010 at 7:28 AM, John Wieczorek tuco@berkeley.edu wrote:
Recommended best practice is to use a controlled vocabulary.
This sounds like an incorrect usage of the term "best practice," to me. It can't be a "best practice" to do something that is impossible, and if a controlled vocabulary doesn't exist... As you indicate, this has a requirement that hasn't yet been met.
It is not a requirement, it is a recommendation. It is not impossible, just make a vocabulary. Well, hopefully with some community buy-in and open access. GBIF's vocabulary registry (http://vocabularies.gbif.org/) comes to mind as a solution.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences _______________________________________________ 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
Can somebody give a "live" example where this has actually been used (i.e. a URI pointing to some RDF or an XML record)?
A "made-up" example based on Ms. Julie Woodruff's relationship given in the DwC Quick Reference guide: http://rs.tdwg.org/dwc/terms/index.htm : subject organism (the offspring) URI: http://example.org/individual/67488 object organism (the mother) URI: http://example.org/individual/23327
If there were a term like voc:mother that said that the object was the mother of the subject, it would be easy to express:
<?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:voc="http://example.org/terms/"
<rdf:Description rdf:about="http://example.org/individual/67488%22%3E <voc:mother rdf:resource="http://example.org/individual/23327" /> </rdf:Description> </rdf:RDF>
Throw that into an RDF validator like http://www.w3.org/RDF/Validator/ and you get a graph that expresses the relationship simply. Now I struggled to express the relationship using terms from the Darwin Core ResourceRelationship class:
<?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dwc="http://rs.tdwg.org/dwc/terms/"
<rdf:Description rdf:about="http://example.org/individual/67488%22%3E dwc:resourceRelationshipID <rdf:Description rdf:about="http://example.org/individual/67488#mother%22%3E <dwc:resourceID rdf:resource="http://example.org/individual/67488" /> <dwc:relatedResourceID rdf:resource="http://example.org/individual/23327" /> dwc:relationshipOfResourcemother of</dwc:relationshipOfResource> <dwc:relationshipAccordingTo rdf:resource="http://example.org/people/woodruff-julie" />
dwc:relationshipEstablishedDate2003-08-17</dwc:relationshipEstablishedDate> dwc:relationshipRemarksmother and offspring collected from the same nest</dwc:relationshipRemarks> </rdf:Description> </dwc:resourceRelationshipID> </rdf:Description> </rdf:RDF>
When I throw that into the validator, I get a graph something like what I imagine, where the URI that I made up for the instance of the relationship (http://example.org/individual/67488#mother) is a named node that connects the subject to the object and all of the properties of the relationship. But I'm not really sure that this is saying what is intended in the DwC standard. Maybe these ResourceRelationship terms are only intended for database tables where the terms are column headings and the instances are rows, and not really for RDF. But the presence of all of the "ID" terms was suggesting to me the use of URIs/GUIDs. Basically I don't understand how this is supposed to work and a functioning example would be helpful.
Steve Baskauf
John Wieczorek wrote:
The term relationshipOfResource has the recommendation to use a controlled vocabulary. The vocabulary does not yet exist - it is an aspect that requires community development. The ResourceRelationship class has the added benefits over the associatedOccurrences term that there is no dependence on the syntax of the content to discern the correct meaning.
From http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource:
Definition: The relationship of the resource identified by relatedResourceID to the subject (optionally identified by the resourceID). Recommended best practice is to use a controlled vocabulary.
Comment: Examples: "duplicate of", "mother of", "endoparasite of", "host to", "sibling of", "valid synonym of", "located within". For discussion see http://code.google.com/p/darwincore/wiki/ResourceRelationship
On Tue, Aug 24, 2010 at 7:07 AM, Mark Wilden <mark@mwilden.com mailto:mark@mwilden.com> wrote:
On Tue, Aug 24, 2010 at 6:24 AM, John Wieczorek <tuco@berkeley.edu <mailto:tuco@berkeley.edu>> wrote: > Note that associatedOccurrences is one of the several terms that are meant > to allow lists of relationships between resources to be captured in a single > field. Others include associatedMedia, associatedReferences, > associatedSequnces, and associatedTaxa. The main purposes of these fields is > to provide a mechanism to share relationship information in a flat > application profile such as the Simple Darwin Core > (http://rs.tdwg.org/dwc/terms/simple/index.htm). If an application profile > isn't constrained by being flat, then there is a much more robust way to > capture relationships, using the ResourceRelationship class and it's > constituent terms (http://rs.tdwg.org/dwc/terms/index.htm#relindex). However, the values of the description of the relationship (http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource) are not controlled, so this still doesn't provide a "community-defined" vocabulary that Bob was asking about. ///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org <mailto:tdwg-content@lists.tdwg.org> http://lists.tdwg.org/mailman/listinfo/tdwg-content
Steve, I havent used the relations in rdf myself, but I would probably use them as primary objects on their own relating 2 dwc resources:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dwc="http://rs.tdwg.org/dwc/terms/%22%3E
<rdf:Description rdf:about="http://example.org/individual/67488#mother%22%3E <rdf:type rdf:resource="http://rs.tdwg.org/dwc/terms/ResourceRelationship" /> <dwc:resourceID rdf:resource="http://example.org/individual/67488" /> <dwc:relatedResourceID rdf:resource="http://example.org/individual/23327" /> dwc:relationshipOfResourcemother of</dwc:relationshipOfResource> <dwc:relationshipAccordingTo rdf:resource="http://example.org/people/woodruff-julie" /> dwc:relationshipEstablishedDate2003-08-17</dwc:relationshipEstablishedDate> dwc:relationshipRemarksmother and offspring collected from the same nest</dwc:relationshipRemarks> </rdf:Description>
<rdf:Description rdf:about="http://example.org/individual/67488%22%3E dwc:scientificNamePuma concolor (Linnaeus, 1771)</dwc:scientificName> <dwc:sex rdf:resource="http://rs.gbif.org/vocabulary/gbif/sex/female" /> </rdf:Description>
<rdf:Description rdf:about="http://example.org/individual/23327%22%3E dwc:scientificNamePuma concolor (Linnaeus, 1771)</dwc:scientificName> <dwc:sex rdf:resource="http://rs.gbif.org/vocabulary/gbif/sex/male" /> </rdf:Description> </rdf:RDF>
I must say it feels strange to use the id terms in rdf to refer to rdf:resources instead of holding ID literals. More natural to the rdf language would be <dwc:resource rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay.
Markus
On Aug 30, 2010, at 4:40, Steve Baskauf wrote:
Can somebody give a "live" example where this has actually been used (i.e. a URI pointing to some RDF or an XML record)?
A "made-up" example based on Ms. Julie Woodruff's relationship given in the DwC Quick Reference guide: http://rs.tdwg.org/dwc/terms/index.htm : subject organism (the offspring) URI: http://example.org/individual/67488 object organism (the mother) URI: http://example.org/individual/23327
If there were a term like voc:mother that said that the object was the mother of the subject, it would be easy to express:
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:voc="http://example.org/terms/"
<rdf:Description rdf:about="http://example.org/individual/67488"> <voc:mother rdf:resource="http://example.org/individual/23327" /> </rdf:Description></rdf:RDF>
Throw that into an RDF validator like http://www.w3.org/RDF/Validator/ and you get a graph that expresses the relationship simply. Now I struggled to express the relationship using terms from the Darwin Core ResourceRelationship class:
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dwc="http://rs.tdwg.org/dwc/terms/"
<rdf:Description rdf:about="http://example.org/individual/67488%22%3E dwc:resourceRelationshipID <rdf:Description rdf:about="http://example.org/individual/67488#mother%22%3E <dwc:resourceID rdf:resource="http://example.org/individual/67488" /> <dwc:relatedResourceID rdf:resource="http://example.org/individual/23327" /> dwc:relationshipOfResourcemother of</dwc:relationshipOfResource> <dwc:relationshipAccordingTo rdf:resource="http://example.org/people/woodruff-julie" /> dwc:relationshipEstablishedDate2003-08-17</dwc:relationshipEstablishedDate> dwc:relationshipRemarksmother and offspring collected from the same nest</dwc:relationshipRemarks> </rdf:Description> </dwc:resourceRelationshipID> </rdf:Description> </rdf:RDF>
When I throw that into the validator, I get a graph something like what I imagine, where the URI that I made up for the instance of the relationship (http://example.org/individual/67488#mother) is a named node that connects the subject to the object and all of the properties of the relationship. But I'm not really sure that this is saying what is intended in the DwC standard. Maybe these ResourceRelationship terms are only intended for database tables where the terms are column headings and the instances are rows, and not really for RDF. But the presence of all of the "ID" terms was suggesting to me the use of URIs/GUIDs. Basically I don't understand how this is supposed to work and a functioning example would be helpful.
Steve Baskauf
John Wieczorek wrote:
The term relationshipOfResource has the recommendation to use a controlled vocabulary. The vocabulary does not yet exist - it is an aspect that requires community development. The ResourceRelationship class has the added benefits over the associatedOccurrences term that there is no dependence on the syntax of the content to discern the correct meaning.
From http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource:
Definition: The relationship of the resource identified by relatedResourceID to the subject (optionally identified by the resourceID). Recommended best practice is to use a controlled vocabulary.
Comment: Examples: "duplicate of", "mother of", "endoparasite of", "host to", "sibling of", "valid synonym of", "located within". For discussion see http://code.google.com/p/darwincore/wiki/ResourceRelationship
On Tue, Aug 24, 2010 at 7:07 AM, Mark Wilden mark@mwilden.com wrote: On Tue, Aug 24, 2010 at 6:24 AM, John Wieczorek tuco@berkeley.edu wrote:
Note that associatedOccurrences is one of the several terms that are meant to allow lists of relationships between resources to be captured in a single field. Others include associatedMedia, associatedReferences, associatedSequnces, and associatedTaxa. The main purposes of these fields is to provide a mechanism to share relationship information in a flat application profile such as the Simple Darwin Core (http://rs.tdwg.org/dwc/terms/simple/index.htm). If an application profile isn't constrained by being flat, then there is a much more robust way to capture relationships, using the ResourceRelationship class and it's constituent terms (http://rs.tdwg.org/dwc/terms/index.htm#relindex).
However, the values of the description of the relationship (http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource) are not controlled, so this still doesn't provide a "community-defined" vocabulary that Bob was asking about.
///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences _______________________________________________ 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 _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Markus, Thanks! After I posted the other night I was thinking that the way I had constructed the RDF was a bit convoluted. Your example is much more straightforward. (although except for a lack of typing on my part the two examples actually result in the same triples).
As you noted, the other thing that my example has is that the record for the offspring makes reference to the dwc:resourceRelationshipID as a way to assert that the offspring has that relationship. I would be interested in some discussion about the appropriate use of the varous dwc:xxxxID terms (e.g. dwc:occurrenceID, dwc:institutionID, etc.). As was the case with the resourceRelationship terms, there aren't a lot of examples showing the proper use of these terms, with the noteworthy exception of http://rs.tdwg.org/dwc/terms/guides/xml/index.htm . As I see it, there are two possible uses of these terms. One (the "first" use) is to identify the actual resource that is the subject of a record. The other (the "second" use) is as an "IDRef" term that connects the subject resource to another record of a different type. In the XML example, we see both uses. In the first example in section 2.7 we see
dcterms:Location dwc:locationIDhttp://guid.mvz.org/sites/arg/127</dwc:locationID> ... more metadata... </dcterms:Location> dwc:Occurrence ... more metadata ... dwc:occurrenceIDurn:catalog:MVZ:Mammals:14523</dwc:occurrenceID> ... more metadata ... dwc:locationIDhttp://guid.mvz.org/sites/arg/127</dwc:locationID> </dwc:Occurrence>
where in the dcterms:Location record, dwc:locationID indicates the identifier for the Location itself (i.e. the subject), while in the dwc:Occurrence record, dwc:locationID refers to the object of the location property of the Occurrence. Because of the freewheeling nature of generic XML files, I guess this is OK. However, when I'm trying to think clearly about how to express relationships in RDF, I've come to decide that I don't like this dual use. I would express the above relationships in RDF as follows:
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... </rdf:Description> <rdf:Description rdf:about="http://resolver.org/urn:catalog:MVZ:Mammals:14523%22%3E <rdfs:type rdf:resource="http://rs.tdwg.org/dwc/terms/Occurrence%22/%3E ... metadata... <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E </rdf:Description>
To me this makes the most sense. It corresponds to the "second" use in the XML example (it indicates the Location property of the Occurrence, i.e. serves as the predicate connecting the subject Occurrence to the object Location). One could also do something like
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
or
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dwc:locationIDhttp://guid.mvz.org/sites/arg/127</dwc:locationID> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
But this seems rather pointless because in the first case, the rdf:about attribute already provides information about the subject of the relationship in a Linked Data manner. In the second case, why have a special term to indicate a literal version of the identifier when there is a more generic and well-known term that is common use? e.g.
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E
dcterms:identifierhttp://guid.mvz.org/sites/arg/127</dcterms:identifier> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
In contrast, there is no simple alternative that I can see (with the possible exception of the dwc:relatedResource, which I wouldn't call a SIMPLE alternative) to using dwc:locationID as the predicate that points to the Location object of an Occurrence subject. Darwin Core doesn't have any terms specifically designed for this (such as "hasLocation" or "hasIdentificatin" for example) but I don't see any reason why the dwc:xxxxID terms couldn't be used this way.
The main issue I can see with the use of these dwc:xxxxID terms is their placement in classes which I guess is related to their rdfs:domain . Although the term description comments at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf (is this the actual place where DwC is officially defined?) say that each term has a rdfs:domain property, they actually don't in the RDF. So the only real clue to the intended subjects of the dwc:xxxxID terms is the placement of the dwc:xxxxID terms into classes. In most cases, a dwc:xxxxID term is placed in the class of the thing that the term is identifying (e.g. occurrenceID is in the Occurrence class, identificationID is in the Identification class, etc.). This would hint that the terms were intended to be used with instances of their class as their subject. However, if the terms were used as IDRefs (the "second" use shown in the XML example) then they really should be in different classes. For example, dwc:locationID could be a member of the class Occurrence, since an Occurrence could have dwc:locationID as a property with an instance of a Location as its object. But then there might be the question of whether an Event could also have a dwc:locationID as a property and dwc:locationID shouldn't be in two classes. In the absence of defined rdfs:domains, I guess the terms can be used with pretty much any subject a user thinks makes sense. As Bob Morris pointed out in a recent post, there aren't very many applications that are doing much in the way of semantic reasoning at this point. But I suppose (hope?) that there could be some in the future, so achieving some kind of consensus on how the terms should be used in RDF would probably be good.
At this point, the dwc:xxxxID terms serve a useful purpose for me in connecting one kind of resource to another (examples in http://bioimages.vanderbilt.edu/ind-baskauf/41870.rdf and http://bioimages.vanderbilt.edu/baskauf/51363.rdf), so unless somebody tells me that's "wrong" and comes up with a better term to describe the relationships I need to describe, I'll keep using the dwc:xxxxID terms as IDRefs.
Comments? Steve
Markus Döring wrote:
I must say it feels strange to use the id terms in rdf to refer to rdf:resources instead of holding ID literals. More natural to the rdf language would be <dwc:resource rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay.
Markus
For background on the state of and reasons for the Darwin Core domains, here are relevant messages in the tdwg-content list archives from the public review period for the standard as it currently stands:
assertions in DwC terms:
http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000019.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000021.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000022.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000024.html
Request for Decision for Public Review of DarwinCore Draft Standard: http://lists.tdwg.org/pipermail/tdwg-content/2009-July/000035.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000088.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000089.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000098.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000092.html
On Tue, Aug 31, 2010 at 12:34 PM, Steve Baskauf < steve.baskauf@vanderbilt.edu> wrote:
Markus, Thanks! After I posted the other night I was thinking that the way I had constructed the RDF was a bit convoluted. Your example is much more straightforward. (although except for a lack of typing on my part the two examples actually result in the same triples).
As you noted, the other thing that my example has is that the record for the offspring makes reference to the dwc:resourceRelationshipID as a way to assert that the offspring has that relationship. I would be interested in some discussion about the appropriate use of the varous dwc:xxxxID terms (e.g. dwc:occurrenceID, dwc:institutionID, etc.). As was the case with the resourceRelationship terms, there aren't a lot of examples showing the proper use of these terms, with the noteworthy exception of http://rs.tdwg.org/dwc/terms/guides/xml/index.htm . As I see it, there are two possible uses of these terms. One (the "first" use) is to identify the actual resource that is the subject of a record. The other (the "second" use) is as an "IDRef" term that connects the subject resource to another record of a different type. In the XML example, we see both uses. In the first example in section 2.7 we see
<dcterms:Location> <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> ... more metadata... </dcterms:Location> <dwc:Occurrence> ... more metadata ... <dwc:occurrenceID>urn:catalog:MVZ:Mammals:14523</dwc:occurrenceID> ... more metadata ... <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> </dwc:Occurrence>where in the dcterms:Location record, dwc:locationID indicates the identifier for the Location itself (i.e. the subject), while in the dwc:Occurrence record, dwc:locationID refers to the object of the location property of the Occurrence. Because of the freewheeling nature of generic XML files, I guess this is OK. However, when I'm trying to think clearly about how to express relationships in RDF, I've come to decide that I don't like this dual use. I would express the above relationships in RDF as follows:
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127"http://guid.mvz.org/sites/arg/127
<rdfs:type rdf:resource="http://purl.org/dc/terms/Location"<http://purl.org/dc/terms/Location>/> ...metadata... </rdf:Description> <rdf:Description rdf:about= "http://resolver.org/urn:catalog:MVZ:Mammals:14523"http://resolver.org/urn:catalog:MVZ:Mammals:14523
<rdfs:type rdf:resource="http://rs.tdwg.org/dwc/terms/Occurrence"<http://rs.tdwg.org/dwc/terms/Occurrence>/> ... metadata... <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127"http://guid.mvz.org/sites/arg/127 /> </rdf:Description>
To me this makes the most sense. It corresponds to the "second" use in the XML example (it indicates the Location property of the Occurrence, i.e. serves as the predicate connecting the subject Occurrence to the object Location). One could also do something like
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127"http://guid.mvz.org/sites/arg/127
<dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127"<http://guid.mvz.org/sites/arg/127>/> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location"http://purl.org/dc/terms/Location /> ...metadata... etc.
or
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127"http://guid.mvz.org/sites/arg/127
<dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location"<http://purl.org/dc/terms/Location>/> ...metadata... etc.
But this seems rather pointless because in the first case, the rdf:about attribute already provides information about the subject of the relationship in a Linked Data manner. In the second case, why have a special term to indicate a literal version of the identifier when there is a more generic and well-known term that is common use? e.g.
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127"http://guid.mvz.org/sites/arg/127
<dcterms:identifier>http://guid.mvz.org/sites/arg/127</dcterms:identifier> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location"http://purl.org/dc/terms/Location /> ...metadata... etc.
In contrast, there is no simple alternative that I can see (with the possible exception of the dwc:relatedResource, which I wouldn't call a SIMPLE alternative) to using dwc:locationID as the predicate that points to the Location object of an Occurrence subject. Darwin Core doesn't have any terms specifically designed for this (such as "hasLocation" or "hasIdentificatin" for example) but I don't see any reason why the dwc:xxxxID terms couldn't be used this way.
The main issue I can see with the use of these dwc:xxxxID terms is their placement in classes which I guess is related to their rdfs:domain . Although the term description comments at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf (is this the actual place where DwC is officially defined?) say that each term has a rdfs:domain property, they actually don't in the RDF. So the only real clue to the intended subjects of the dwc:xxxxID terms is the placement of the dwc:xxxxID terms into classes. In most cases, a dwc:xxxxID term is placed in the class of the thing that the term is identifying (e.g. occurrenceID is in the Occurrence class, identificationID is in the Identification class, etc.). This would hint that the terms were intended to be used with instances of their class as their subject. However, if the terms were used as IDRefs (the "second" use shown in the XML example) then they really should be in different classes. For example, dwc:locationID could be a member of the class Occurrence, since an Occurrence could have dwc:locationID as a property with an instance of a Location as its object. But then there might be the question of whether an Event could also have a dwc:locationID as a property and dwc:locationID shouldn't be in two classes. In the absence of defined rdfs:domains, I guess the terms can be used with pretty much any subject a user thinks makes sense. As Bob Morris pointed out in a recent post, there aren't very many applications that are doing much in the way of semantic reasoning at this point. But I suppose (hope?) that there could be some in the future, so achieving some kind of consensus on how the terms should be used in RDF would probably be good.
At this point, the dwc:xxxxID terms serve a useful purpose for me in connecting one kind of resource to another (examples in http://bioimages.vanderbilt.edu/ind-baskauf/41870.rdf and http://bioimages.vanderbilt.edu/baskauf/51363.rdf), so unless somebody tells me that's "wrong" and comes up with a better term to describe the relationships I need to describe, I'll keep using the dwc:xxxxID terms as IDRefs.
Comments? Steve
Markus Döring wrote:
I must say it feels strange to use the id terms in rdf to refer to rdf:resources instead of holding ID literals. More natural to the rdf language would be <dwc:resource rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay.
Markus
-- 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-6707http://bioimages.vanderbilt.edu
Thanks for the references, John. Sorry for bringing up a settled issue - I didn't mean to plow old ground again (I think I wasn't on the list yet when these posts came out). I can see the advantage of not actually specifying a domain for the DwC terms in terms of not squelching innovative uses of the DwC terms. However, rdfs:domain issue aside, if I'm understanding the cited archived messages correctly, the point of putting the DwC terms into classes at all is to help to clarify what they mean and how they should be used. The point of my post was that the dwc:xxxxID terms have two possible uses, one of which is consistent with their current placement in classes and one (the one that I think is most useful) that is not.
I guess the reason that I'm bringing this up is that I'm using these terms pretty heavily in a way that I'm not sure is the way they are intended. What I would like is either some confirmation from the community that this use is OK or else we need to define some other terms that will get the job done. Darwin Core doesn't at this point have an "instruction book" except for the Google Code Wiki and that Wiki has no descriptions yet for most of the terms in the vocabulary. I don't feel comfortable creating my own meanings for terms that don't have clear guidelines. After all, the point of having Darwin Core terms is so that people use them to refer to the same "thing".
I would also like to make two suggestions about the RDF file at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf . One is that either someone needs to fix the "human.xsl" file so that it renders the RDF in a web browser, or remove the xml-stylesheet tag and just let web browsers display the raw RDF XML. This has not rendered properly since the rdf was moved over from the tdwg domain (I think at least six months ago). It doesn't matter to me since I know how to use "view source" to see the source XML, but it's really pretty shoddy form for the definition of a major vocabulary. The second thing is that if the DwC terms are not going to have rdfs:domains specified, then somebody should take those erroneous comments out of the dwcterms.rdf file. I think that would be allowable without requiring the issuing of a new version because it's correcting an error and doesn't actually change the DwC standard itself.
Steve
John Wieczorek wrote:
For background on the state of and reasons for the Darwin Core domains, here are relevant messages in the tdwg-content list archives from the public review period for the standard as it currently stands:
assertions in DwC terms:
http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000019.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000021.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000022.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000024.html
Request for Decision for Public Review of DarwinCore Draft Standard:
http://lists.tdwg.org/pipermail/tdwg-content/2009-July/000035.html
http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000088.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000089.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000098.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000092.html
On Tue, Aug 31, 2010 at 12:34 PM, Steve Baskauf <steve.baskauf@vanderbilt.edu mailto:steve.baskauf@vanderbilt.edu> wrote:
Markus, Thanks! After I posted the other night I was thinking that the way I had constructed the RDF was a bit convoluted. Your example is much more straightforward. (although except for a lack of typing on my part the two examples actually result in the same triples). As you noted, the other thing that my example has is that the record for the offspring makes reference to the dwc:resourceRelationshipID as a way to assert that the offspring has that relationship. I would be interested in some discussion about the appropriate use of the varous dwc:xxxxID terms (e.g. dwc:occurrenceID, dwc:institutionID, etc.). As was the case with the resourceRelationship terms, there aren't a lot of examples showing the proper use of these terms, with the noteworthy exception of http://rs.tdwg.org/dwc/terms/guides/xml/index.htm . As I see it, there are two possible uses of these terms. One (the "first" use) is to identify the actual resource that is the subject of a record. The other (the "second" use) is as an "IDRef" term that connects the subject resource to another record of a different type. In the XML example, we see both uses. In the first example in section 2.7 we see <dcterms:Location> <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> ... more metadata... </dcterms:Location> <dwc:Occurrence> ... more metadata ... <dwc:occurrenceID>urn:catalog:MVZ:Mammals:14523</dwc:occurrenceID> ... more metadata ... <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> </dwc:Occurrence> where in the dcterms:Location record, dwc:locationID indicates the identifier for the Location itself (i.e. the subject), while in the dwc:Occurrence record, dwc:locationID refers to the object of the location property of the Occurrence. Because of the freewheeling nature of generic XML files, I guess this is OK. However, when I'm trying to think clearly about how to express relationships in RDF, I've come to decide that I don't like this dual use. I would express the above relationships in RDF as follows: <rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127" <http://guid.mvz.org/sites/arg/127>> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location" <http://purl.org/dc/terms/Location>/> ...metadata... </rdf:Description> <rdf:Description rdf:about="http://resolver.org/urn:catalog:MVZ:Mammals:14523" <http://resolver.org/urn:catalog:MVZ:Mammals:14523>> <rdfs:type rdf:resource="http://rs.tdwg.org/dwc/terms/Occurrence" <http://rs.tdwg.org/dwc/terms/Occurrence>/> ... metadata... <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127" <http://guid.mvz.org/sites/arg/127>/> </rdf:Description> To me this makes the most sense. It corresponds to the "second" use in the XML example (it indicates the Location property of the Occurrence, i.e. serves as the predicate connecting the subject Occurrence to the object Location). One could also do something like <rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127" <http://guid.mvz.org/sites/arg/127>> <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127" <http://guid.mvz.org/sites/arg/127>/> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location" <http://purl.org/dc/terms/Location>/> ...metadata... etc. or <rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127" <http://guid.mvz.org/sites/arg/127>> <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location" <http://purl.org/dc/terms/Location>/> ...metadata... etc. But this seems rather pointless because in the first case, the rdf:about attribute already provides information about the subject of the relationship in a Linked Data manner. In the second case, why have a special term to indicate a literal version of the identifier when there is a more generic and well-known term that is common use? e.g. <rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127" <http://guid.mvz.org/sites/arg/127>> <dcterms:identifier>http://guid.mvz.org/sites/arg/127</dcterms:identifier> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location" <http://purl.org/dc/terms/Location>/> ...metadata... etc. In contrast, there is no simple alternative that I can see (with the possible exception of the dwc:relatedResource, which I wouldn't call a SIMPLE alternative) to using dwc:locationID as the predicate that points to the Location object of an Occurrence subject. Darwin Core doesn't have any terms specifically designed for this (such as "hasLocation" or "hasIdentificatin" for example) but I don't see any reason why the dwc:xxxxID terms couldn't be used this way. The main issue I can see with the use of these dwc:xxxxID terms is their placement in classes which I guess is related to their rdfs:domain . Although the term description comments at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf (is this the actual place where DwC is officially defined?) say that each term has a rdfs:domain property, they actually don't in the RDF. So the only real clue to the intended subjects of the dwc:xxxxID terms is the placement of the dwc:xxxxID terms into classes. In most cases, a dwc:xxxxID term is placed in the class of the thing that the term is identifying (e.g. occurrenceID is in the Occurrence class, identificationID is in the Identification class, etc.). This would hint that the terms were intended to be used with instances of their class as their subject. However, if the terms were used as IDRefs (the "second" use shown in the XML example) then they really should be in different classes. For example, dwc:locationID could be a member of the class Occurrence, since an Occurrence could have dwc:locationID as a property with an instance of a Location as its object. But then there might be the question of whether an Event could also have a dwc:locationID as a property and dwc:locationID shouldn't be in two classes. In the absence of defined rdfs:domains, I guess the terms can be used with pretty much any subject a user thinks makes sense. As Bob Morris pointed out in a recent post, there aren't very many applications that are doing much in the way of semantic reasoning at this point. But I suppose (hope?) that there could be some in the future, so achieving some kind of consensus on how the terms should be used in RDF would probably be good. At this point, the dwc:xxxxID terms serve a useful purpose for me in connecting one kind of resource to another (examples in http://bioimages.vanderbilt.edu/ind-baskauf/41870.rdf and http://bioimages.vanderbilt.edu/baskauf/51363.rdf), so unless somebody tells me that's "wrong" and comes up with a better term to describe the relationships I need to describe, I'll keep using the dwc:xxxxID terms as IDRefs. Comments? Steve Markus Döring wrote:I must say it feels strange to use the id terms in rdf to refer to rdf:resources instead of holding ID literals. More natural to the rdf language would be <dwc:resource rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay. Markus-- 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
Steve, I was about to fix the xsl when I thought we might first want to decide on what the whole dwc "site" should be offering.
Currently we have: - normative html definitions for all current and historical term versions - 2 guidelines (xml & text) on how to use dwc terms with the respective technology including xml schemas and other files needed for that. - dwcterms.rdf and dwctermshistory.rdf for rdf definitions of the terms. Primarily these are intended to support the use of dwc terms in rdf and allow a resolution of the term URIs into rdf.
It would be really nice if you or someone else would add a new guideline on how to use dwc terms in the context of rdf. For that I am wondering if dwctermshistory.rdf is needed at all or whether its not good enough to maintain the html version only. And in the light of having already normative html versions I support the idea of removing the xsl stylesheet from the rdf files.
In regards to the resolution of the term URIs I have setup some content negotiation that takes you to the rdf in case you request "application/rdf+xml" - otherwise it defaults to the html definitions. I think that is one more reason that we dont need any xsl on the rdf anymore.
http://rs.tdwg.org/dwc/terms/taxonID now gets redirected to either: http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf http://darwincore.googlecode.com/svn/trunk/terms/index.htm#taxonID
For the domains of the ID terms its good to have a more in depth discussion. To me those ID terms can always both, a primary or a foreign key depending where you use them. For RDF as you say there is a natural primary key with rdf:about for all rdf resources, so the purpose for dwc ID terms should be restricted to act as "foreign keys", i.e. have no domain at all (unless we want to go into the discussion which is the definite set of accepted domains and how they actually relate - sth we had decided dwc will not do but wait for the proper ontology work to take on). For that discussion Id also like to point out that analogeous to rdf we have created guidelines for using dwc terms in normalised xml that defines "classes". In the matching xml schema actually all ID terms are allowed in every class: http://rs.tdwg.org/dwc/terms/guides/xml/index.htm#classes http://rs.tdwg.org/dwc/xsd/tdwg_dwc_class_terms.xsd
In the html definitions we assign a "class" to all terms, some of which are "all" though (for example all record level ones). We should consider for all ID terms a Class of "all" too, so we can use them as "foreign keys" as well. In the historical html file we additionally have a "Has Domain" definition. It seems to me this is a left over from the initial definitions and this can be removed.
In the dwcterms.rdf definitions we dont use rdfs:domain at all right now. Btw, Ive changed rdfs:replaces to dcterms:replaces in the rdf files.
If we all agree I would propose to do the following additional changes: - remove xsl from rdf files - remove dwctermshistory.rdf in favor over html alone? - remove "Has Domain" from term history.
Markus
On Sep 6, 2010, at 2:38, Steve Baskauf wrote:
Thanks for the references, John. Sorry for bringing up a settled issue - I didn't mean to plow old ground again (I think I wasn't on the list yet when these posts came out). I can see the advantage of not actually specifying a domain for the DwC terms in terms of not squelching innovative uses of the DwC terms. However, rdfs:domain issue aside, if I'm understanding the cited archived messages correctly, the point of putting the DwC terms into classes at all is to help to clarify what they mean and how they should be used. The point of my post was that the dwc:xxxxID terms have two possible uses, one of which is consistent with their current placement in classes and one (the one that I think is most useful) that is not.
I guess the reason that I'm bringing this up is that I'm using these terms pretty heavily in a way that I'm not sure is the way they are intended. What I would like is either some confirmation from the community that this use is OK or else we need to define some other terms that will get the job done. Darwin Core doesn't at this point have an "instruction book" except for the Google Code Wiki and that Wiki has no descriptions yet for most of the terms in the vocabulary. I don't feel comfortable creating my own meanings for terms that don't have clear guidelines. After all, the point of having Darwin Core terms is so that people use them to refer to the same "thing".
I would also like to make two suggestions about the RDF file at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf . One is that either someone needs to fix the "human.xsl" file so that it renders the RDF in a web browser, or remove the xml-stylesheet tag and just let web browsers display the raw RDF XML. This has not rendered properly since the rdf was moved over from the tdwg domain (I think at least six months ago). It doesn't matter to me since I know how to use "view source" to see the source XML, but it's really pretty shoddy form for the definition of a major vocabulary. The second thing is that if the DwC terms are not going to have rdfs:domains specified, then somebody should take those erroneous comments out of the dwcterms.rdf file. I think that would be allowable without requiring the issuing of a new version because it's correcting an error and doesn't actually change the DwC standard itself.
Steve
John Wieczorek wrote:
For background on the state of and reasons for the Darwin Core domains, here are relevant messages in the tdwg-content list archives from the public review period for the standard as it currently stands:
assertions in DwC terms:
http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000019.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000021.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000022.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000024.html
Request for Decision for Public Review of DarwinCore Draft Standard:
http://lists.tdwg.org/pipermail/tdwg-content/2009-July/000035.html
http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000088.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000089.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000098.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000092.html
On Tue, Aug 31, 2010 at 12:34 PM, Steve Baskauf steve.baskauf@vanderbilt.edu wrote: Markus, Thanks! After I posted the other night I was thinking that the way I had constructed the RDF was a bit convoluted. Your example is much more straightforward. (although except for a lack of typing on my part the two examples actually result in the same triples).
As you noted, the other thing that my example has is that the record for the offspring makes reference to the dwc:resourceRelationshipID as a way to assert that the offspring has that relationship. I would be interested in some discussion about the appropriate use of the varous dwc:xxxxID terms (e.g. dwc:occurrenceID, dwc:institutionID, etc.). As was the case with the resourceRelationship terms, there aren't a lot of examples showing the proper use of these terms, with the noteworthy exception of http://rs.tdwg.org/dwc/terms/guides/xml/index.htm . As I see it, there are two possible uses of these terms. One (the "first" use) is to identify the actual resource that is the subject of a record. The other (the "second" use) is as an "IDRef" term that connects the subject resource to another record of a different type. In the XML example, we see both uses. In the first example in section 2.7 we see
<dcterms:Location> <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> ... more metadata... </dcterms:Location> <dwc:Occurrence> ... more metadata ... <dwc:occurrenceID>urn:catalog:MVZ:Mammals:14523</dwc:occurrenceID> ... more metadata ... <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> </dwc:Occurrence>where in the dcterms:Location record, dwc:locationID indicates the identifier for the Location itself (i.e. the subject), while in the dwc:Occurrence record, dwc:locationID refers to the object of the location property of the Occurrence. Because of the freewheeling nature of generic XML files, I guess this is OK. However, when I'm trying to think clearly about how to express relationships in RDF, I've come to decide that I don't like this dual use. I would express the above relationships in RDF as follows:
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... </rdf:Description> <rdf:Description rdf:about="http://resolver.org/urn:catalog:MVZ:Mammals:14523%22%3E <rdfs:type rdf:resource="http://rs.tdwg.org/dwc/terms/Occurrence%22/%3E ... metadata... <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E </rdf:Description>
To me this makes the most sense. It corresponds to the "second" use in the XML example (it indicates the Location property of the Occurrence, i.e. serves as the predicate connecting the subject Occurrence to the object Location). One could also do something like
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
or
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dwc:locationIDhttp://guid.mvz.org/sites/arg/127</dwc:locationID> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
But this seems rather pointless because in the first case, the rdf:about attribute already provides information about the subject of the relationship in a Linked Data manner. In the second case, why have a special term to indicate a literal version of the identifier when there is a more generic and well-known term that is common use? e.g.
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dcterms:identifierhttp://guid.mvz.org/sites/arg/127</dcterms:identifier> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
In contrast, there is no simple alternative that I can see (with the possible exception of the dwc:relatedResource, which I wouldn't call a SIMPLE alternative) to using dwc:locationID as the predicate that points to the Location object of an Occurrence subject. Darwin Core doesn't have any terms specifically designed for this (such as "hasLocation" or "hasIdentificatin" for example) but I don't see any reason why the dwc:xxxxID terms couldn't be used this way.
The main issue I can see with the use of these dwc:xxxxID terms is their placement in classes which I guess is related to their rdfs:domain . Although the term description comments at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf (is this the actual place where DwC is officially defined?) say that each term has a rdfs:domain property, they actually don't in the RDF. So the only real clue to the intended subjects of the dwc:xxxxID terms is the placement of the dwc:xxxxID terms into classes. In most cases, a dwc:xxxxID term is placed in the class of the thing that the term is identifying (e.g. occurrenceID is in the Occurrence class, identificationID is in the Identification class, etc.). This would hint that the terms were intended to be used with instances of their class as their subject. However, if the terms were used as IDRefs (the "second" use shown in the XML example) then they really should be in different classes. For example, dwc:locationID could be a member of the class Occurrence, since an Occurrence could have dwc:locationID as a property with an instance of a Location as its object. But then there might be the question of whether an Event could also have a dwc:locationID as a property and dwc:locationID shouldn't be in two classes. In the absence of defined rdfs:domains, I guess the terms can be used with pretty much any subject a user thinks makes sense. As Bob Morris pointed out in a recent post, there aren't very many applications that are doing much in the way of semantic reasoning at this point. But I suppose (hope?) that there could be some in the future, so achieving some kind of consensus on how the terms should be used in RDF would probably be good.
At this point, the dwc:xxxxID terms serve a useful purpose for me in connecting one kind of resource to another (examples in http://bioimages.vanderbilt.edu/ind-baskauf/41870.rdf and http://bioimages.vanderbilt.edu/baskauf/51363.rdf), so unless somebody tells me that's "wrong" and comes up with a better term to describe the relationships I need to describe, I'll keep using the dwc:xxxxID terms as IDRefs.
Comments? Steve
Markus Döring wrote:
I must say it feels strange to use the id terms in rdf to refer to rdf:resources instead of holding ID literals. More natural to the rdf language would be <dwc:resource rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay.
Markus
-- 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
-- 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
Markus, This all makes sense to me. I think that putting the xxxxID terms in the "All" class would solve the problem I brought up and would help to clarify their use.
I would be happy to take a shot at writing a guide for using DwC in RDF if others are willing to give feedback. I have a couple other things I need to finish first, but should be able to create something in the near term - probably before the TDWG meeting.
Steve
Markus Döring wrote:
Steve, I was about to fix the xsl when I thought we might first want to decide on what the whole dwc "site" should be offering.
Currently we have:
- normative html definitions for all current and historical term versions
- 2 guidelines (xml & text) on how to use dwc terms with the respective technology including xml schemas and other files needed for that.
- dwcterms.rdf and dwctermshistory.rdf for rdf definitions of the terms. Primarily these are intended to support the use of dwc terms in rdf and allow a resolution of the term URIs into rdf.
It would be really nice if you or someone else would add a new guideline on how to use dwc terms in the context of rdf. For that I am wondering if dwctermshistory.rdf is needed at all or whether its not good enough to maintain the html version only. And in the light of having already normative html versions I support the idea of removing the xsl stylesheet from the rdf files.
In regards to the resolution of the term URIs I have setup some content negotiation that takes you to the rdf in case you request "application/rdf+xml" - otherwise it defaults to the html definitions. I think that is one more reason that we dont need any xsl on the rdf anymore.
http://rs.tdwg.org/dwc/terms/taxonID now gets redirected to either: http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf http://darwincore.googlecode.com/svn/trunk/terms/index.htm#taxonID
For the domains of the ID terms its good to have a more in depth discussion. To me those ID terms can always both, a primary or a foreign key depending where you use them. For RDF as you say there is a natural primary key with rdf:about for all rdf resources, so the purpose for dwc ID terms should be restricted to act as "foreign keys", i.e. have no domain at all (unless we want to go into the discussion which is the definite set of accepted domains and how they actually relate - sth we had decided dwc will not do but wait for the proper ontology work to take on). For that discussion Id also like to point out that analogeous to rdf we have created guidelines for using dwc terms in normalised xml that defines "classes". In the matching xml schema actually all ID terms are allowed in every class: http://rs.tdwg.org/dwc/terms/guides/xml/index.htm#classes http://rs.tdwg.org/dwc/xsd/tdwg_dwc_class_terms.xsd
In the html definitions we assign a "class" to all terms, some of which are "all" though (for example all record level ones). We should consider for all ID terms a Class of "all" too, so we can use them as "foreign keys" as well. In the historical html file we additionally have a "Has Domain" definition. It seems to me this is a left over from the initial definitions and this can be removed.
In the dwcterms.rdf definitions we dont use rdfs:domain at all right now. Btw, Ive changed rdfs:replaces to dcterms:replaces in the rdf files.
If we all agree I would propose to do the following additional changes:
- remove xsl from rdf files
- remove dwctermshistory.rdf in favor over html alone?
- remove "Has Domain" from term history.
Markus
On Sep 6, 2010, at 2:38, Steve Baskauf wrote:
Thanks for the references, John. Sorry for bringing up a settled issue - I didn't mean to plow old ground again (I think I wasn't on the list yet when these posts came out). I can see the advantage of not actually specifying a domain for the DwC terms in terms of not squelching innovative uses of the DwC terms. However, rdfs:domain issue aside, if I'm understanding the cited archived messages correctly, the point of putting the DwC terms into classes at all is to help to clarify what they mean and how they should be used. The point of my post was that the dwc:xxxxID terms have two possible uses, one of which is consistent with their current placement in classes and one (the one that I think is most useful) that is not.
I guess the reason that I'm bringing this up is that I'm using these terms pretty heavily in a way that I'm not sure is the way they are intended. What I would like is either some confirmation from the community that this use is OK or else we need to define some other terms that will get the job done. Darwin Core doesn't at this point have an "instruction book" except for the Google Code Wiki and that Wiki has no descriptions yet for most of the terms in the vocabulary. I don't feel comfortable creating my own meanings for terms that don't have clear guidelines. After all, the point of having Darwin Core terms is so that people use them to refer to the same "thing".
I would also like to make two suggestions about the RDF file at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf . One is that either someone needs to fix the "human.xsl" file so that it renders the RDF in a web browser, or remove the xml-stylesheet tag and just let web browsers display the raw RDF XML. This has not rendered properly since the rdf was moved over from the tdwg domain (I think at least six months ago). It doesn't matter to me since I know how to use "view source" to see the source XML, but it's really pretty shoddy form for the definition of a major vocabulary. The second thing is that if the DwC terms are not going to have rdfs:domains specified, then somebody should take those erroneous comments out of the dwcterms.rdf file. I think that would be allowable without requiring the issuing of a new version because it's correcting an error and doesn't actually change the DwC standard itself.
Steve
John Wieczorek wrote:
For background on the state of and reasons for the Darwin Core domains, here are relevant messages in the tdwg-content list archives from the public review period for the standard as it currently stands:
assertions in DwC terms:
http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000019.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000021.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000022.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000024.html
Request for Decision for Public Review of DarwinCore Draft Standard:
http://lists.tdwg.org/pipermail/tdwg-content/2009-July/000035.html
http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000088.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000089.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000098.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000092.html
On Tue, Aug 31, 2010 at 12:34 PM, Steve Baskauf steve.baskauf@vanderbilt.edu wrote: Markus, Thanks! After I posted the other night I was thinking that the way I had constructed the RDF was a bit convoluted. Your example is much more straightforward. (although except for a lack of typing on my part the two examples actually result in the same triples).
As you noted, the other thing that my example has is that the record for the offspring makes reference to the dwc:resourceRelationshipID as a way to assert that the offspring has that relationship. I would be interested in some discussion about the appropriate use of the varous dwc:xxxxID terms (e.g. dwc:occurrenceID, dwc:institutionID, etc.). As was the case with the resourceRelationship terms, there aren't a lot of examples showing the proper use of these terms, with the noteworthy exception of http://rs.tdwg.org/dwc/terms/guides/xml/index.htm . As I see it, there are two possible uses of these terms. One (the "first" use) is to identify the actual resource that is the subject of a record. The other (the "second" use) is as an "IDRef" term that connects the subject resource to another record of a different type. In the XML example, we see both uses. In the first example in section 2.7 we see
<dcterms:Location> <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> ... more metadata... </dcterms:Location> <dwc:Occurrence> ... more metadata ... <dwc:occurrenceID>urn:catalog:MVZ:Mammals:14523</dwc:occurrenceID> ... more metadata ... <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> </dwc:Occurrence>where in the dcterms:Location record, dwc:locationID indicates the identifier for the Location itself (i.e. the subject), while in the dwc:Occurrence record, dwc:locationID refers to the object of the location property of the Occurrence. Because of the freewheeling nature of generic XML files, I guess this is OK. However, when I'm trying to think clearly about how to express relationships in RDF, I've come to decide that I don't like this dual use. I would express the above relationships in RDF as follows:
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... </rdf:Description> <rdf:Description rdf:about="http://resolver.org/urn:catalog:MVZ:Mammals:14523%22%3E <rdfs:type rdf:resource="http://rs.tdwg.org/dwc/terms/Occurrence%22/%3E ... metadata... <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E </rdf:Description>
To me this makes the most sense. It corresponds to the "second" use in the XML example (it indicates the Location property of the Occurrence, i.e. serves as the predicate connecting the subject Occurrence to the object Location). One could also do something like
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
or
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dwc:locationIDhttp://guid.mvz.org/sites/arg/127</dwc:locationID> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
But this seems rather pointless because in the first case, the rdf:about attribute already provides information about the subject of the relationship in a Linked Data manner. In the second case, why have a special term to indicate a literal version of the identifier when there is a more generic and well-known term that is common use? e.g.
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dcterms:identifierhttp://guid.mvz.org/sites/arg/127</dcterms:identifier> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
In contrast, there is no simple alternative that I can see (with the possible exception of the dwc:relatedResource, which I wouldn't call a SIMPLE alternative) to using dwc:locationID as the predicate that points to the Location object of an Occurrence subject. Darwin Core doesn't have any terms specifically designed for this (such as "hasLocation" or "hasIdentificatin" for example) but I don't see any reason why the dwc:xxxxID terms couldn't be used this way.
The main issue I can see with the use of these dwc:xxxxID terms is their placement in classes which I guess is related to their rdfs:domain . Although the term description comments at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf (is this the actual place where DwC is officially defined?) say that each term has a rdfs:domain property, they actually don't in the RDF. So the only real clue to the intended subjects of the dwc:xxxxID terms is the placement of the dwc:xxxxID terms into classes. In most cases, a dwc:xxxxID term is placed in the class of the thing that the term is identifying (e.g. occurrenceID is in the Occurrence class, identificationID is in the Identification class, etc.). This would hint that the terms were intended to be used with instances of their class as their subject. However, if the terms were used as IDRefs (the "second" use shown in the XML example) then they really should be in different classes. For example, dwc:locationID could be a member of the class Occurrence, since an Occurrence could have dwc:locationID as a property with an instance of a Location as its object. But then there might be the question of whether an Event could also have a dwc:locationID as a property and dwc:locationID shouldn't be in two classes. In the absence of defined rdfs:domains, I guess the terms can be used with pretty much any subject a user thinks makes sense. As Bob Morris pointed out in a recent post, there aren't very many applications that are doing much in the way of semantic reasoning at this point. But I suppose (hope?) that there could be some in the future, so achieving some kind of consensus on how the terms should be used in RDF would probably be good.
At this point, the dwc:xxxxID terms serve a useful purpose for me in connecting one kind of resource to another (examples in http://bioimages.vanderbilt.edu/ind-baskauf/41870.rdf and http://bioimages.vanderbilt.edu/baskauf/51363.rdf), so unless somebody tells me that's "wrong" and comes up with a better term to describe the relationships I need to describe, I'll keep using the dwc:xxxxID terms as IDRefs.
Comments? Steve
Markus Döring wrote:
I must say it feels strange to use the id terms in rdf to refer to rdf:resources instead of holding ID literals. More natural to the rdf language would be <dwc:resource rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay.
Markus
-- 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
-- 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
.
I've produced a limping OWL2 version in connection with several projects I'm involved with. Later this week I'll have it tuned a little more and put it on the table for discussion. It likely could be informed by and/or inform any advice about use of the current dwcterms.rdf.
Bob
On Tue, Sep 7, 2010 at 6:42 AM, Steve Baskauf steve.baskauf@vanderbilt.edu wrote:
Markus, This all makes sense to me. I think that putting the xxxxID terms in the "All" class would solve the problem I brought up and would help to clarify their use.
I would be happy to take a shot at writing a guide for using DwC in RDF if others are willing to give feedback. I have a couple other things I need to finish first, but should be able to create something in the near term - probably before the TDWG meeting.
Steve
Markus Döring wrote:
Steve, I was about to fix the xsl when I thought we might first want to decide on what the whole dwc "site" should be offering.
Currently we have:
- normative html definitions for all current and historical term versions
- 2 guidelines (xml & text) on how to use dwc terms with the respective
technology including xml schemas and other files needed for that.
- dwcterms.rdf and dwctermshistory.rdf for rdf definitions of the terms.
Primarily these are intended to support the use of dwc terms in rdf and allow a resolution of the term URIs into rdf.
It would be really nice if you or someone else would add a new guideline on how to use dwc terms in the context of rdf. For that I am wondering if dwctermshistory.rdf is needed at all or whether its not good enough to maintain the html version only. And in the light of having already normative html versions I support the idea of removing the xsl stylesheet from the rdf files.
In regards to the resolution of the term URIs I have setup some content negotiation that takes you to the rdf in case you request "application/rdf+xml" - otherwise it defaults to the html definitions. I think that is one more reason that we dont need any xsl on the rdf anymore.
http://rs.tdwg.org/dwc/terms/taxonID now gets redirected to either: http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf http://darwincore.googlecode.com/svn/trunk/terms/index.htm#taxonID
For the domains of the ID terms its good to have a more in depth discussion. To me those ID terms can always both, a primary or a foreign key depending where you use them. For RDF as you say there is a natural primary key with rdf:about for all rdf resources, so the purpose for dwc ID terms should be restricted to act as "foreign keys", i.e. have no domain at all (unless we want to go into the discussion which is the definite set of accepted domains and how they actually relate - sth we had decided dwc will not do but wait for the proper ontology work to take on). For that discussion Id also like to point out that analogeous to rdf we have created guidelines for using dwc terms in normalised xml that defines "classes". In the matching xml schema actually all ID terms are allowed in every class: http://rs.tdwg.org/dwc/terms/guides/xml/index.htm#classes http://rs.tdwg.org/dwc/xsd/tdwg_dwc_class_terms.xsd
In the html definitions we assign a "class" to all terms, some of which are "all" though (for example all record level ones). We should consider for all ID terms a Class of "all" too, so we can use them as "foreign keys" as well. In the historical html file we additionally have a "Has Domain" definition. It seems to me this is a left over from the initial definitions and this can be removed.
In the dwcterms.rdf definitions we dont use rdfs:domain at all right now. Btw, Ive changed rdfs:replaces to dcterms:replaces in the rdf files.
If we all agree I would propose to do the following additional changes:
- remove xsl from rdf files
- remove dwctermshistory.rdf in favor over html alone?
- remove "Has Domain" from term history.
Markus
On Sep 6, 2010, at 2:38, Steve Baskauf wrote:
Thanks for the references, John. Sorry for bringing up a settled issue - I didn't mean to plow old ground again (I think I wasn't on the list yet when these posts came out). I can see the advantage of not actually specifying a domain for the DwC terms in terms of not squelching innovative uses of the DwC terms. However, rdfs:domain issue aside, if I'm understanding the cited archived messages correctly, the point of putting the DwC terms into classes at all is to help to clarify what they mean and how they should be used. The point of my post was that the dwc:xxxxID terms have two possible uses, one of which is consistent with their current placement in classes and one (the one that I think is most useful) that is not.
I guess the reason that I'm bringing this up is that I'm using these terms pretty heavily in a way that I'm not sure is the way they are intended. What I would like is either some confirmation from the community that this use is OK or else we need to define some other terms that will get the job done. Darwin Core doesn't at this point have an "instruction book" except for the Google Code Wiki and that Wiki has no descriptions yet for most of the terms in the vocabulary. I don't feel comfortable creating my own meanings for terms that don't have clear guidelines. After all, the point of having Darwin Core terms is so that people use them to refer to the same "thing".
I would also like to make two suggestions about the RDF file at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf . One is that either someone needs to fix the "human.xsl" file so that it renders the RDF in a web browser, or remove the xml-stylesheet tag and just let web browsers display the raw RDF XML. This has not rendered properly since the rdf was moved over from the tdwg domain (I think at least six months ago). It doesn't matter to me since I know how to use "view source" to see the source XML, but it's really pretty shoddy form for the definition of a major vocabulary. The second thing is that if the DwC terms are not going to have rdfs:domains specified, then somebody should take those erroneous comments out of the dwcterms.rdf file. I think that would be allowable without requiring the issuing of a new version because it's correcting an error and d oesn't actually change the DwC standard itself.
Steve
John Wieczorek wrote:
For background on the state of and reasons for the Darwin Core domains, here are relevant messages in the tdwg-content list archives from the public review period for the standard as it currently stands:
assertions in DwC terms:
http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000019.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000021.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000022.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000024.html
Request for Decision for Public Review of DarwinCore Draft Standard:
http://lists.tdwg.org/pipermail/tdwg-content/2009-July/000035.html
http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000088.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000089.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000098.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000092.html
On Tue, Aug 31, 2010 at 12:34 PM, Steve Baskauf steve.baskauf@vanderbilt.edu wrote: Markus, Thanks! After I posted the other night I was thinking that the way I had constructed the RDF was a bit convoluted. Your example is much more straightforward. (although except for a lack of typing on my part the two examples actually result in the same triples).
As you noted, the other thing that my example has is that the record for the offspring makes reference to the dwc:resourceRelationshipID as a way to assert that the offspring has that relationship. I would be interested in some discussion about the appropriate use of the varous dwc:xxxxID terms (e.g. dwc:occurrenceID, dwc:institutionID, etc.). As was the case with the resourceRelationship terms, there aren't a lot of examples showing the proper use of these terms, with the noteworthy exception of http://rs.tdwg.org/dwc/terms/guides/xml/index.htm . As I see it, there are two possible uses of these terms. One (the "first" use) is to identify the actual resource that is the subject of a record. The other (the "second" use) is as an "IDRef" term that connects the subject resource to another record of a different type. In the XML example, we see both uses. In the first example in section 2.7 we see
<dcterms:Location> <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> ... more metadata... </dcterms:Location> <dwc:Occurrence> ... more metadata ... <dwc:occurrenceID>urn:catalog:MVZ:Mammals:14523</dwc:occurrenceID> ... more metadata ... <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID> </dwc:Occurrence>where in the dcterms:Location record, dwc:locationID indicates the identifier for the Location itself (i.e. the subject), while in the dwc:Occurrence record, dwc:locationID refers to the object of the location property of the Occurrence. Because of the freewheeling nature of generic XML files, I guess this is OK. However, when I'm trying to think clearly about how to express relationships in RDF, I've come to decide that I don't like this dual use. I would express the above relationships in RDF as follows:
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... </rdf:Description> rdf:Description rdf:about="http://resolver.org/urn:catalog:MVZ:Mammals:14523" <rdfs:type rdf:resource="http://rs.tdwg.org/dwc/terms/Occurrence%22/%3E ... metadata... <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E </rdf:Description>
To me this makes the most sense. It corresponds to the "second" use in the XML example (it indicates the Location property of the Occurrence, i.e. serves as the predicate connecting the subject Occurrence to the object Location). One could also do something like
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
or
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dwc:locationIDhttp://guid.mvz.org/sites/arg/127</dwc:locationID> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
But this seems rather pointless because in the first case, the rdf:about attribute already provides information about the subject of the relationship in a Linked Data manner. In the second case, why have a special term to indicate a literal version of the identifier when there is a more generic and well-known term that is common use? e.g.
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E
dcterms:identifierhttp://guid.mvz.org/sites/arg/127</dcterms:identifier> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
In contrast, there is no simple alternative that I can see (with the possible exception of the dwc:relatedResource, which I wouldn't call a SIMPLE alternative) to using dwc:locationID as the predicate that points to the Location object of an Occurrence subject. Darwin Core doesn't have any terms specifically designed for this (such as "hasLocation" or "hasIdentificatin" for example) but I don't see any reason why the dwc:xxxxID terms couldn't be used this way.
The main issue I can see with the use of these dwc:xxxxID terms is their placement in classes which I guess is related to their rdfs:domain . Although the term description comments at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf (is this the actual place where DwC is officially defined?) say that each term has a rdfs:domain property, they actually don't in the RDF. So the only real clue to the intended subjects of the dwc:xxxxID terms is the placement of the dwc:xxxxID terms into classes. In most cases, a dwc:xxxxID term is placed in the class of the thing that the term is identifying (e.g. occurrenceID is in the Occurrence class, identificationID is in the Identification class, etc.). This would hint that the terms were intended to be used with instances of their class as their subject. However, if the terms were used as IDRefs (the "second" use shown in the XML example) then they really should be in different classes. For example, dwc:locationID could be a member of the class Occurrence, since an Occurrence could have dwc:locationID as a property with an instance of a Location as its object. But then there might be the question of whether an Event could also have a dwc:locationID as a property and dwc:locationID shouldn't be in two classes. In the absence of defined rdfs:domains, I guess the terms can be used with pretty much any subject a user thinks makes sense. As Bob Morris pointed out in a recent post, there aren't very many applications that are doing much in the way of semantic reasoning at this point. But I suppose (hope?) that there could be some in the future, so achieving some kind of consensus on how the terms should be used in RDF would probably be good.
At this point, the dwc:xxxxID terms serve a useful purpose for me in connecting one kind of resource to another (examples in http://bioimages.vanderbilt.edu/ind-baskauf/41870.rdf and http://bioimages.vanderbilt.edu/baskauf/51363.rdf), so unless somebody tells me that's "wrong" and comes up with a better term to describe the relationships I need to describe, I'll keep using the dwc:xxxxID terms as IDRefs.
Comments? Steve
Markus Döring wrote:
I must say it feels strange to use the id terms in rdf to refer to rdf:resources instead of holding ID literals. More natural to the rdf language would be <dwc:resource rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay.
Markus
-- 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
-- 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
.
-- 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
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Comments inline.
On Sun, Sep 5, 2010 at 11:16 PM, Markus Döring m.doering@mac.com wrote:
Steve, I was about to fix the xsl when I thought we might first want to decide on what the whole dwc "site" should be offering.
Currently we have:
- normative html definitions for all current and historical term versions
- 2 guidelines (xml & text) on how to use dwc terms with the respective
technology including xml schemas and other files needed for that.
- dwcterms.rdf and dwctermshistory.rdf for rdf definitions of the terms.
Primarily these are intended to support the use of dwc terms in rdf and allow a resolution of the term URIs into rdf.
It would be really nice if you or someone else would add a new guideline on how to use dwc terms in the context of rdf. For that I am wondering if dwctermshistory.rdf is needed at all or whether its not good enough to maintain the html version only. And in the light of having already normative html versions I support the idea of removing the xsl stylesheet from the rdf files.
A bit of history. The dwctermshistory.rdf is meant to be a complete and single normative document of the Darwin Core terms whether current or obsolete. The term description content in HTML on the Darwin Core site can be generated from the dwctermshistory.rdf file, but not vice versa. I would not remove it. The dcterms.rdf file was created for convenience. It is meant to contain only what is necessary for the Darwin Core as it currently stands, not all of the history that lead up to its current form. If you don't need to know about how something came to be in its current form, dcterms.rdf should be sufficient. I'm neutral about the xsl stylesheet, because I don't use it or maintain it. I think it might be useful to have a functional XSL stylesheet as one of the tools available from the Tools and Applications section of the Darwin Core wiki (http://code.google.com/p/darwincore/wiki/ToolsAndApplications), as there are people who would like to adapt it for customized documentation based on the normative standard.
In regards to the resolution of the term URIs I have setup some content negotiation that takes you to the rdf in case you request "application/rdf+xml" - otherwise it defaults to the html definitions. I think that is one more reason that we dont need any xsl on the rdf anymore.
http://rs.tdwg.org/dwc/terms/taxonID now gets redirected to either: http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf http://darwincore.googlecode.com/svn/trunk/terms/index.htm#taxonID
For the domains of the ID terms its good to have a more in depth discussion. To me those ID terms can always both, a primary or a foreign key depending where you use them. For RDF as you say there is a natural primary key with rdf:about for all rdf resources, so the purpose for dwc ID terms should be restricted to act as "foreign keys", i.e. have no domain at all (unless we want to go into the discussion which is the definite set of accepted domains and how they actually relate - sth we had decided dwc will not do but wait for the proper ontology work to take on).
For that discussion Id also like to point out that analogeous to rdf we have
created guidelines for using dwc terms in normalised xml that defines "classes". In the matching xml schema actually all ID terms are allowed in every class: http://rs.tdwg.org/dwc/terms/guides/xml/index.htm#classes http://rs.tdwg.org/dwc/xsd/tdwg_dwc_class_terms.xsd
In the html definitions we assign a "class" to all terms, some of which are "all" though (for example all record level ones). We should consider for all ID terms a Class of "all" too, so we can use them as "foreign keys" as well. In the historical html file we additionally have a "Has Domain" definition. It seems to me this is a left over from the initial definitions and this can be removed.
Just so everyone knows, the "assignment" of a class to a term in Darwin Core is nothing more than an organizational convenience accomplished through an rdf predicate called organizedInClass created specifically for this purpose. This predicate allows to make these convenient groupings without going so far as to put say that a term is a property of a given class.
In the dwcterms.rdf definitions we dont use rdfs:domain at all right now. Btw, Ive changed rdfs:replaces to dcterms:replaces in the rdf files.
If we all agree I would propose to do the following additional changes:
- remove xsl from rdf files
I agree if you move functional versions to the Tools wiki page.
- remove dwctermshistory.rdf in favor over html alone?
I don't agree. This is a normative document.
- remove "Has Domain" from term history.
If there is any chance that we will use domains for anything in the future I would leave this as it is. Otherwise, there may be a number of places in the documentation where hasDomain needs to be excised. Since it is functionally equivalent to have hasDomain blank, I would leave it that way until we are absolutely sure.
Markus
On Sep 6, 2010, at 2:38, Steve Baskauf wrote:
Thanks for the references, John. Sorry for bringing up a settled issue -
I didn't mean to plow old ground again (I think I wasn't on the list yet when these posts came out). I can see the advantage of not actually specifying a domain for the DwC terms in terms of not squelching innovative uses of the DwC terms. However, rdfs:domain issue aside, if I'm understanding the cited archived messages correctly, the point of putting the DwC terms into classes at all is to help to clarify what they mean and how they should be used. The point of my post was that the dwc:xxxxID terms have two possible uses, one of which is consistent with their current placement in classes and one (the one that I think is most useful) that is not.
I guess the reason that I'm bringing this up is that I'm using these
terms pretty heavily in a way that I'm not sure is the way they are intended. What I would like is either some confirmation from the community that this use is OK or else we need to define some other terms that will get the job done. Darwin Core doesn't at this point have an "instruction book" except for the Google Code Wiki and that Wiki has no descriptions yet for most of the terms in the vocabulary. I don't feel comfortable creating my own meanings for terms that don't have clear guidelines. After all, the point of having Darwin Core terms is so that people use them to refer to the same "thing".
I would also like to make two suggestions about the RDF file at
http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf . One is that either someone needs to fix the "human.xsl" file so that it renders the RDF in a web browser, or remove the xml-stylesheet tag and just let web browsers display the raw RDF XML. This has not rendered properly since the rdf was moved over from the tdwg domain (I think at least six months ago). It doesn't matter to me since I know how to use "view source" to see the source XML, but it's really pretty shoddy form for the definition of a major vocabulary. The second thing is that if the DwC terms are not going to have rdfs:domains specified, then somebody should take those erroneous comments out of the dwcterms.rdf file. I think that would be allowable without requiring the issuing of a new version because it's correcting an error and doesn't actually change the DwC standard itself.
Steve
John Wieczorek wrote:
For background on the state of and reasons for the Darwin Core domains,
here are relevant messages in the tdwg-content list archives from the public review period for the standard as it currently stands:
assertions in DwC terms:
http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000019.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000021.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000022.html http://lists.tdwg.org/pipermail/tdwg-content/2009-June/000024.html
Request for Decision for Public Review of DarwinCore Draft Standard:
http://lists.tdwg.org/pipermail/tdwg-content/2009-July/000035.html
http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000088.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000089.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000098.html http://lists.tdwg.org/pipermail/tdwg-content/2009-August/000092.html
On Tue, Aug 31, 2010 at 12:34 PM, Steve Baskauf <
steve.baskauf@vanderbilt.edu> wrote:
Markus, Thanks! After I posted the other night I was thinking that the way I
had constructed the RDF was a bit convoluted. Your example is much more straightforward. (although except for a lack of typing on my part the two examples actually result in the same triples).
As you noted, the other thing that my example has is that the record for
the offspring makes reference to the dwc:resourceRelationshipID as a way to assert that the offspring has that relationship. I would be interested in some discussion about the appropriate use of the varous dwc:xxxxID terms (e.g. dwc:occurrenceID, dwc:institutionID, etc.). As was the case with the resourceRelationship terms, there aren't a lot of examples showing the proper use of these terms, with the noteworthy exception of http://rs.tdwg.org/dwc/terms/guides/xml/index.htm . As I see it, there are two possible uses of these terms. One (the "first" use) is to identify the actual resource that is the subject of a record. The other (the "second" use) is as an "IDRef" term that connects the subject resource to another record of a different type. In the XML example, we see both uses. In the first example in section 2.7 we see
<dcterms:Location> <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID>
... more metadata... </dcterms:Location> <dwc:Occurrence> ... more metadata ...dwc:occurrenceIDurn:catalog:MVZ:Mammals:14523</dwc:occurrenceID>
... more metadata ... <dwc:locationID>http://guid.mvz.org/sites/arg/127</dwc:locationID>
</dwc:Occurrence>where in the dcterms:Location record, dwc:locationID indicates the
identifier for the Location itself (i.e. the subject), while in the dwc:Occurrence record, dwc:locationID refers to the object of the location property of the Occurrence. Because of the freewheeling nature of generic XML files, I guess this is OK. However, when I'm trying to think clearly about how to express relationships in RDF, I've come to decide that I don't like this dual use. I would express the above relationships in RDF as follows:
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... </rdf:Description> <rdf:Description rdf:about="
http://resolver.org/urn:catalog:MVZ:Mammals:14523%22%3E
<rdfs:type rdf:resource="http://rs.tdwg.org/dwc/terms/Occurrence"/> ... metadata... <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127"/></rdf:Description>
To me this makes the most sense. It corresponds to the "second" use in
the XML example (it indicates the Location property of the Occurrence, i.e. serves as the predicate connecting the subject Occurrence to the object Location). One could also do something like
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E <dwc:locationID rdf:resource="http://guid.mvz.org/sites/arg/127%22/%3E <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
or
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dwc:locationIDhttp://guid.mvz.org/sites/arg/127</dwc:locationID> <rdfs:type rdf:resource="http://purl.org/dc/terms/Location%22/%3E ...metadata... etc.
But this seems rather pointless because in the first case, the rdf:about
attribute already provides information about the subject of the relationship in a Linked Data manner. In the second case, why have a special term to indicate a literal version of the identifier when there is a more generic and well-known term that is common use? e.g.
<rdf:Description rdf:about="http://guid.mvz.org/sites/arg/127%22%3E dcterms:identifierhttp://guid.mvz.org/sites/arg/127
</dcterms:identifier>
<rdfs:type rdf:resource="http://purl.org/dc/terms/Location"/> ...metadata...etc.
In contrast, there is no simple alternative that I can see (with the
possible exception of the dwc:relatedResource, which I wouldn't call a SIMPLE alternative) to using dwc:locationID as the predicate that points to the Location object of an Occurrence subject. Darwin Core doesn't have any terms specifically designed for this (such as "hasLocation" or "hasIdentificatin" for example) but I don't see any reason why the dwc:xxxxID terms couldn't be used this way.
The main issue I can see with the use of these dwc:xxxxID terms is their
placement in classes which I guess is related to their rdfs:domain . Although the term description comments at http://darwincore.googlecode.com/svn/trunk/rdf/dwcterms.rdf (is this the actual place where DwC is officially defined?) say that each term has a rdfs:domain property, they actually don't in the RDF. So the only real clue to the intended subjects of the dwc:xxxxID terms is the placement of the dwc:xxxxID terms into classes. In most cases, a dwc:xxxxID term is placed in the class of the thing that the term is identifying (e.g. occurrenceID is in the Occurrence class, identificationID is in the Identification class, etc.). This would hint that the terms were intended to be used with instances of their class as their subject. However, if the terms were used as IDRefs (the "second" use shown in the XML example) then they really should be in different classes. For example, dwc:locationID could be a member of the class Occurrence, since an Occurrence could have dwc:locationID as a property with an instance of a Location as its object. But then there might be the question of whether an Event could also have a dwc:locationID as a property and dwc:locationID shouldn't be in two classes. In the absence of defined rdfs:domains, I guess the terms can be used with pretty much any subject a user thinks makes sense. As Bob Morris pointed out in a recent post, there aren't very many applications that are doing much in the way of semantic reasoning at this point. But I suppose (hope?) that there could be some in the future, so achieving some kind of consensus on how the terms should be used in RDF would probably be good.
At this point, the dwc:xxxxID terms serve a useful purpose for me in
connecting one kind of resource to another (examples in http://bioimages.vanderbilt.edu/ind-baskauf/41870.rdf and http://bioimages.vanderbilt.edu/baskauf/51363.rdf), so unless somebody tells me that's "wrong" and comes up with a better term to describe the relationships I need to describe, I'll keep using the dwc:xxxxID terms as IDRefs.
Comments? Steve
Markus Döring wrote:
I must say it feels strange to use the id terms in rdf to refer to
rdf:resources instead of holding ID literals.
More natural to the rdf language would be <dwc:resource
rdf:resource="..." /> and <dwc:relatedResource rdf:resource="..." /> I suppose, but the dwc vocabulary was built for different technologies, not rdf alone. So I guess thats the price we have to pay.
Markus
-- 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
-- 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
participants (5)
-
Bob Morris -
John Wieczorek -
Mark Wilden -
Markus Döring -
Steve Baskauf