[foaf-dev] FOAF and dcterms:creator/dcterms:Agent
tbaker at tbaker.de
Tue Feb 23 09:13:28 CET 2010
[Adding the dc-usage list in Cc:]
On Tue, Feb 23, 2010 at 09:13:06PM +0000, Damian Steer wrote:
> On 23 Feb 2010, at 20:47, Hogan, Aidan wrote:
> > So, I just noted in the new version of FOAF that you relate foaf:maker
> > to dcterms:creator using owl:equivalentProperty. This seems contrary to
> > precedent elsewhere in the specification, where you use
> > subclass/subproperty relations to relate local terms with external
> > terms.
> > My main concern is that FOAF is mandating the translation of
> > dcterms:creator triples into foaf:maker triples, somehow "redefining"
> > the external dcterms:creator term as a subproperty of foaf:maker. As
> > general vocabulary etiquette, I would prefer to see vocabularies purely
> > extend external terms, and avoid saying anything about external terms
> > which will affect reasoning on the "instance triples" which use them.
> In general I'd agree with much of this, but this particular case seems entirely reasonable. I really can't see there's any difference between the terms. That both exist is unfortunate, but that's what history has provided.
> foaf:maker rdfs:subPropertyOf dc:creator .
> is ok, but doesn't project the foaf:maker claims into dc land.
> dc:creator rdfs:subPropertyOf foaf:maker .
> would be very useful for dc-consumers, giving them access to the foaf corners of the web.
The DCMI Usage Board discussed this at its meeting last October
. We agreed in principle to make an equivalent assertion but
took an action to explore whether this should more properly be
done with mutual sub-property assertions or with
It just so happened that I had the rare opportunity two weeks
later to discuss this very question at a VoCamp in Washington DC
with Richard Cyganiak, Pat Hayes, and Jon Phipps. In that
discussion, we came to the conclusion that making two mutual
sub-property assertions would be preferable, because the two
statements taken together would be logically equivalent to
owl:equivalentProperty, but they would be attaining this
equivalence through the _socially_ significant act of
If I understand Aidan's concern, his is an issue that also came
up in the discussion: the notion that one would seem to
"project" triples onto external terms that may be unwarranted -
possibly constituting a form of "namespace hijacking".
We left the meeting resolved to write this up as a proposed best
practice for discussion on a list somewhere. On further
reflection, however, Richard then leaned back towards the
argument that if you think they are equivalent, "why not just
say so" with owl:equivalentProperty (an argument hard
to refute), and concluded that his DERI colleague's
notion of "hijacking" would not really apply. And in the
meantime, Dan has now used owl:equivalentProperty in FOAF.
I still have a slight preference for the subProperty option
because I think it is in general a bit more polite and avoids
implying that one party really understands the intended
semantics of the other property well enough to make the stronger
At any rate, it has been on my to-do list for a long time to
follow up on this, so I would be interested in hearing opinions
on this list. DCMI is in principle ready to make such a
statement, and if opinions tend towards owl:equivalentProperty,
I for one would not object.
Either way, however, I do see this particular equivalence as a
small but precedent-setting test case for the sorts of mapping
assertions that should probably be encouraged more generally.
Alot of equivalent properties are going to be coined (or
discovered after the fact), so the need to assert mappings will
only grow. In this particular case, I believe we do understand
the intended semantics to make a strong statement, but do we
want to encourage people to make such strong statements in general?
Whichever way we settle this, I would welcome volunteers to help
us vet a one-page explanation for publication by DCMI laying out
the issue and articulating the rationale for the approach we end
up following - as a stake in the ground for good practice.
Tom Baker <tbaker at tbaker.de>
More information about the foaf-dev