Andy said:

> I agree that we need to be careful, especially when, as you 
> suggest, tags are not necessarily "about" something.  The 
> unfortunate part is that people and systems are lumping tags 
> into dc:subject.  So I think a valid question to ask is: do 
> you want to relax the semantics for dc:subject?

They aren't mine to relax ;-) The semantics of dc:subject (and the other
DCMI properties) is/are defined/managed by the DCMI Usage Board.

But if it was up to me to answer that question, I'd probably say "no". 
 
> To summarize your argument about tags:
> 1) Tags are sometimes used to indicate identity.
> 2) Tags are sometimes used to indicate genre.
> 3) Tags are sometimes used to indicate aboutness.
> 4) Tags are sometimes used to indicate relationships.
> 5) dc:relation more appropriately models tags than dc:subject

I wasn't saying that the dc:relation property was ideal or that it was
the exact equivalent of the "has-tag" relationship: not all assertions
using dc:relation are has-tag relations (IMHO). But it is "a better fit"
for the "has-tag" relationship than the dc:subject in the sense that it
doesn't imply something about the has-tag relationship that is false.

> What I find interesting about this summary is that in DC, 
> identity is expressed by dc:identifier, genre is expressed by 
> dc:type, aboutness is expressed by dc:subject and 
> relationships are expressed by dc:relation.
> 
> I'll put forth the following intellectual argument.  Perhaps 
> the DCMI Abstract Model incorrectly models dc:identifier, 
> dc:type and dc:subject.

Just to clarify: the DCMI Abstract Model doesn't say anything
specifically about dc:identifier, dc:type and dc:subject. Actually it
does about dc:type, though that's a matter of discussion at the moment
too - but it certainly doesn't about dc:subject or the other DCMI-owned
properties. It's the Usage Board who specify the DCMI-owned properties,
including any relationships between properties. 

> Given your position, one could argue that dc:identifier 
> really specifies a specific relationship to the resource, 
> e.g., identity where the content is a handle or "tag".  The 
> same being true for dc:type and dc:subject.  You could argue 
> that the model should look something like:
> 
> dc:relation
>   *:tag
>     dc:identifier
>     dc:type
>     dc:subject
> 
> * some unknown namespace
> 
> where dc:subject is-a class of *:tag, dc:type is-a class of 
> *:tag, dc:identifier is-a class of *:tag, and *:tag is-a 
> class of dc:relation.

These terms are properties not classes, and the relationship would be, I
think, a subproperty relationship. i.e. if property:p is a subproperty
if property:q, then every time I create a triple 

resource:a property:p resource:b

I imply a second triple

resource:a property:q resource:b

I certainly agree that all properties (including dc:identifier,
dc:subject and dc:type, and other:tag - any property anyone can dream
up! ;-)) could be declared as subproperties of dc:relation. (It doesn't
bother me that DCMI doesn't state this formally because although doing
so might satisfy the pedant in me, it wouldn't enable anyone to generate
any useful additional information.)

But I don't think I'd go as far as saying that dc:identifier, dc:subject
and dc:type are subproperties of other:tag. Yes, I was suggesting that
some "has-tag" relations are "has-genre" relations (and so on), but
_not_ that all "has-genre"/"has-identifier"/"has-topic" relations (and
so on) are "has-tag" relations.

It depends what we really mean by the "has-tag" relationship - what
information we want to represent and why. Is it useful to say that every
assertion of a has-genre/has-identifier/has-topic relationship implies
an assertion of a has-tag relationship?  Does every assertion of _any_
relationship imply an assertion of a has-tag relationship? Does
"has-title" imply "has-tag"?

Or are we trying to capture something specific with the concept of a
"has-tag" relationship? 
 
At this point, I'd be inclined to say the latter, there is something
distinctive about the has-tag relationship, and on that basis I wouldn't
make dc:type/dc:subject/dc:identifier (etc) subproperties of the
other:tag property - not all dc:subject (etc) statements imply other:tag
statements. If you push me to justify that, and explain exactly where
the distinction lies, just now, I would struggle to provide a clear
rationale. But my instinctive response is that I'm not sure that making
those subproperty assertions would be helpful. 

> This Heretic Abstract Model (HAM :) doesn't change the 
> semantics for dc:identifier, dc:type or dc:subject.  They 
> just indicate classes of *:tag whose semantics are identity, 
> genre/form and aboutness.  In addition, HAM's *:tag could be 
> used as a broad class in social tagging system allowing them 
> to define their own special types in a similar manner to the 
> strategy I mentioned for defining new VES (Vocabulary 
> Encoding Schemes).

We're still working within the framework of the DCAM and/or RDF/RDFS, so
I don't think it's really a Heretic Abstract Model - no need to expect
the Inquisition just yet! ;-)

Cheers
Pete