[tdwg-content] Expressing some relationships in DwC?

[Richard Pyle]

>  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.