W3C home > Mailing lists > Public > public-esw-thes@w3.org > March 2004

Re: Difference between dc:subject and foaf:topic

From: Charles McCathieNevile <charles@w3.org>
Date: Mon, 15 Mar 2004 17:12:33 -0500 (EST)
To: Dan Brickley <danbri@w3.org>
Cc: Libby Miller <Libby.Miller@bristol.ac.uk>, "Miles, AJ (Alistair) " <A.J.Miles@rl.ac.uk>, "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>
Message-ID: <Pine.LNX.4.55.0403151311260.24260@homer.w3.org>

Looking at the original question from Alistair:

Which of the following two options should we recommend using (?) :

<rdf:Description rdf:about="http://foo.com/aWebPage.html">
        <dc:subject rdf:resource="urn:swad-e:example/concept/FastFood"/>


<rdf:Description rdf:about="http://foo.com/aWebPage.html">
        <foaf:topic rdf:resource="urn:swad-e:example/concept/FastFood"/>

and thinking about this, I get to the following:

FOAF defines topic in a smarter way that Dublin Core, because it insists that
the object is a resource. (It also insists that the range be a Web page,
which on further reflection isn't so cool because I have a lot of use cases
for noting the topic of some part of a page and as far as I can tell I can't
do that nicely in FOAF unless I am prepared to lump all the topics together).

As I understand Dan's argument, it is that Dublin Core has a particular use
pattern which does things like confusing things and their names, and FOAF is
meant to avoid this.

It seems to me that there is a lot of mileage to be made by easy mappings
from existing data, and there is a lot of value in having well-specified

If we were to suggest Dublin Core, I would be concerned that we are
supporting something very underspecified, in a way that might prove to be a
pain in the medium term. If we exclude it, we are cutting off one of the very
widely-used vocabularies.

So it seems to me a good idea to try and find something that is better
constrained than dc:subject, but which has essentially similar semantics for
its core meaning.

I had thought that foaf:topic would fit that bill, subject to the proviso
that some dc:subject information can't be shoe-horned into working as
foaf:topic information. But I can't envisage an instance of foaf:topic which
is not legal value for dc:subject - since it will accept anything. Nor can I
think of an instance where the meaning of a foaf:topic would be different if
it were interpreted as a dc:subject. That makes it a good target in my
understanding for declaring something as a subProperty.

Which would allow us to recommend the better-constrained foaf:topic wherever
the initial data could be made to meet its constraints (perhaps by clarifying
teh inital modelling, which is probably in itself beneficial), and showing
some examples of how to use the very widely used (there is perhaps more
dc:title and dc:creator information available, and possibly even the
officially meaningless but widely claimed dc:author) dc:subject to get a head
start on bringing your data with you instead of rebuilding it.

A few comments inserted below, because I am not sure that I have understood
everything, nor that I have managed to explain myself well yet.



On Fri, 12 Mar 2004, Dan Brickley wrote:

>* Charles McCathieNevile <charles@w3.org> [2004-03-12 11:34-0500]
>> It isn't clear from that explanation what the difference is, since unless you
>> talk about the domain and range of foaf:topic it's hard to understand how
>> there is any.
>dc:subject relates a document to a code that stands for some thing the
>doc is about.
>foaf:topic relates a document to some thing that the doc is about.
>...the difference is w.r.t. layers of indirection: where dc:subject uses
>an external taxonomy, set out in advance, foaf:topic relies on any chunk
>of RDF that is handy for describing the thing. It's an interesting
>stylistic and representational difference that seems really quite
>unfortunately hard to explain clearly...

dc:subject best practice uses some code, but doesn't say anything about how
to set it out. foaf:topic uses some code, and requires it to be of type
rdf:Resource. I don't see any formal refinement to that, although the
practical result is that foaf:topic tends to be easier to deal with in some
useful way.

>> The fact that foaf:topic has a defined domain of foaf:Document and a range of
>> rdf:Resource means that it's a bit more restricted than dc:subject which can
>> happily live with a literal value, but there doesn't seem to be much else
>> that can be used to pick between them (on my reading of the two sets of
>> specifications).
>They differ importantly, just as you differ from your homepage, and XML
>differs from library subject codes for XML. With dc:subject there is a
>whole other world squeezed into the representation: the world of
>subject/topic codes. With foaf:topic, the RDF itself does that work,
>removing subject/topic codes from the list of things the RDF needs to
>describe. See above re this being hard to describe :(

I don't think this is hard to describe, and I think you have made a pretty
good description. (Although it makes me wonder why foaf: doesn't finish in #

>> If I was trying to define the way I see the web I would write somewhere that
>> foaf:topic seems to me like a subProperty of dc:subject.
>that would imply that any pair of things related by foaf:topic are also
>related by dc:subject. This isn't so, since the values taken by
>dc:subject are various forms of subject code, whereas the values taken
>by foaf:topic are the things that those subject codes denote. So
>declaring a subPropertyOf relation would confuse those two levels.

I don't think this is true. dc:subject says the best practice is to use
subject codes defined somehow. it doesn't ever say "except those which are
defined with something useful like RDF" (because it is syntax-neutral). The
fact that people don't often do that today in a meaningful way isn't such a
big deal is it?

>>	Being a believer in
>> living language, and in language as an attempt to provide identifiers for
>> concepts in such a way thhat we are convinced we mean the same thing, this
>> doesn't strike me as a bad thing to do. But since we are inventing RDF
>> vocabulary creation, it is something I would treat with care - especially
>> while we don't yet have good methods for dealing with conflicting statements,
>> including conflicting statements about how vocaublaries are defined.
>We defintely need to to allow for vocabulary evolution, it might be
>interesting to compare the two approaches...

I think vocabulary evolution is one issue, but usage evolution is perhaps
different - tricker and more important at the same time :-\


Received on Monday, 15 March 2004 17:12:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:10 UTC