Well, I guess one could make the case that people who are not interested in RDF might want a DwC-only way to express this.
Maybe "not interested" is not the best way to put it. Perhaps "not ready".
I guess my point was that we seem to be talking about trying to invent a method to accomplish something where there already is a well-established way to do it. DwC at the present has a very "flat" database orientation and I think the resource-relationship terms were introduced to allow for a "flat" way to describe resources that aren't really flat (i.e. 1:M or M:M).
Agreed. But resourceRelationship is already in there, and as we both seem to have discovered, nobody appears to be using it. So...I think we at least need to clarify how it's supposed to be used in a DwC context; or we should let it die a slow, quiet death of non-use. I guess I'm OK either way; but given that it exists, and given that we seem to have people who don't want to go all the way to RDF triples for all data exchange purposes (yet), perhaps we should examine how best to use this already-existing DwC class, modify it as needed to make it actually useful to those who want to use it, and let it die after we're all pumping our data out via RDF that works against a solid, stable ontology.
It's based on the term definition and examples at http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource which recommend a controlled vocabulary and give strings as the only
examples.
I think that in keeping with other precedents in DwC your suggestion of "relationshipOfResourceID" might be better.
Agreed.
Well, in terms of the type for the subject, I don't think there is any
reason to
create a new term for that. There is already rdf:type to do exactly
that.
Well...there's also dcterms:type, which is already part of DwC. The problem, though, that this would apply to resourceRelationshipID (i.e., the "type" of relationship itself); not to the resourceID. Technically, you'd need to resolve resourceID to retrieve dcterms:type for the subject item. I don't know how rdf:type is intended to work in this context.
Whether it would matter if DwC imports that term or not, I don't know.
How is it different from dcterms:type?
It is certainly already "well known". relatedResourceType could be a
shortcut
to accomplish what you want for the object. We are still left with the
problem
that there is no consensus about what are the core "types" (which I
consider
to be equivalent to the question of what are the core classes) in our
community.
I've argued for adopting the DwC classes where they will do the job, but I
haven't
heard too many people express support for that and there are necessary
classes
that don't exist (yet) within DwC (e.g. a class for agents).
Can't DwC simply import terms from foaf, like it does with dcterms?
Also, there are classes in the TDWG ontology that may or may not overlap
with
DwC classes (most notably dwc:Taxon). Do we use therm?
Perhaps. I guess it would depend on demand and specific use cases.
So in order for this to be of much value, it seems to me that there is a
need to
hash out the core classes/types. I was hoping the RDF group would take
that up,
but it's not clear to me that there is support for doing that at this
stage
(was it discussed at the meeting?).
Yes, it was discussed at the meeting -- at least in the BiSciCol group and the RDF group. There seemed to me a growing interest in resurrecting a discussion about a TDWG ontology, to see if it could be finished. Not in full-spec detail; but at least to the level of the DwC classes (and other like-level entities). I only caught part of the discussion at the RDF group, but Cam was there. It seemed to me that several people were citing the Darwin-SW ontology as a starting point (ahem....).
The day when those are reality will certainly come (I hope!), but in the mean time, we still need an
exchange
mechanism for certain content that is more complex than what can be met
with
DwCA.
I agree. I don't see any reason why the same relationships that one can
express in
RDF triples couldn't be expressed in a database table. But some of the
issues that
must be addressed to make that work are (in my mind) the same ones that
need
to be addressed to make RDF work as a metadata transfer mechanism. They could probably both be worked out at the same time to some extent.
Yes, agreed! They should absolutely be worked out at the same time.
Well, I actually wasn't so much concerned with the mechanics of actually handling the RDF as the fact that it makes more sense to me to have a generic URI to describe a particular kind of resource relationship than to
have to parse out and interpret a string for every relationship that is to be described. One of the points of RDF is that it doesn't have a single representation (e.g. it doesn't have to be represented as XML). But the subject, predicate, object relationship is basic and that's pretty
much what we are talking about here.
OK, I agree. It could be that resourceRelationship is a "gateway drug" to get people into thinking in terms of triples.
Rich
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.