Andrew said:

> It's not clear to me why you would want to invent a new 
> namespace for the definition of dctag when it was related to 
> but not purporting to be dc:subject.  This seems similar to 
> what is done with encoding schemes, e.g., dct:DDC, dct:LCC, 
> dct:LCSH, dct:MESH, dct:NLM, dct:TGN and dct:UDC. Taken from 
> "Expressing Qualified Dublin Core in RDF /XML" document:
>
>  <dc:subject>
>    <dcterms:MESH>
>      <rdf:value>D08.586.682.075.400</rdf:value>
>      <rdfs:label>Formate Dehydrogenase</rdfs:label>
>    </dcterms:MESH>
>  </dc:subject>
> 
> It seems like you could just define a new encoding scheme, 
> e.g., dcterm:TAG, to handle the semantics of social tagging.  
> However, that might not be enough.  Organizations such as 
> Flickr, YouTube, etc. may desire slightly different semantics 
> for their social tagging.  DCMI probably doesn't want to keep 
> defining new encoding schemes on a regular basis.

Leaving aside the "which namespace do we use" issue for a second, I
think we need to be careful not to confuse two very different types of
thing, two different types of term used in DC metadata: properties and
vocabulary encoding schemes.

A property is a specific type of relationship. The dc:subject property
is one specific type of relationship, defined and named by DCMI (using a
DCMI-owned URI) and described by DCMI in human-readable terms as "The
topic of the content of the resource." 

A vocabulary encoding scheme, on the other hand, is something quite
different. According to the DCMI Abstract Model, it is a class of which
the value is an instance. N.B. This is one of the areas where a change
is susggested in the proposed revisions to the DCAM - the suggestion is
that we change the concept of VES to something like "an enumerated set
of which the value is a member", and that is _not_ represented as an
instance/class relationship, but for the purposes of this discussion I
don't think that matters too much. The point is that a VES is a
different thing from a property and "plays a different role" in DC
metadata.

So, when I use the dc:subject property in an RDF triple or a DC
statement, I'm making an assertion that

resource:A has-as-topic resource:B   

Or maybe more colloquially

resource:A is-about resource:B

I could specify that resource:B is an instance/member of dcterms:LCSH or
an instance/member of dcterms:DDC (i.e. I could specify a vocabulary
encoding scheme for the value). That provides some additional
information about the value - it's an instance/member of some specified
class/set - but that doesn't change the nature of the relationship that
I'm asserting between resource:A and resource:B. The property referred
to in my triple/statement is still the same: the dc:subject property.
I'm still asserting a "has-topic"/"is-about" relationship.

If resource:B is a tag, and I use it as the object in an RDF triple or a
DC statement with the dc:subject property, then I'm making an assertion
that

resource:A has-as-topic tag:T   

Or

resource:A is-about tag:T

I could specify that tag:T is an instance/member of petej:TagSet (i.e. I
could specify a vocabulary encoding scheme for that value), but - as in
the example above of LCSH and DDC - adding the vocabulary encoding
scheme provides additional information about the value, but it does not
change the assertion I am making about the nature of the relationship
between resource:A and tag:T. It's the property which specifies the
nature of the relationship, and as long as I'm using the dc:subject
property, I'm asserting a "has-topic"/"is-about" relationship.

And in my previous message, I was arguing that when people "tag"
resources, yes, they are asserting a relationship between the tagged
resource and a tag (but see also note below), but it is _not_ true that
the relationship they are asserting is always a "has-topic"/"is-about"
relationship. On the contrary, people use tagging to represent all sorts
of relationships  - ownership, status, "rating", related-location. A
resource tagged "to-read" on del.icio.us isn't "about" the concept of
not having been read yet. Well, yes, I accept that somewhere out there
someone has written a weblog post describing the pile of paperbacks on
their bedside table and a del.icio.us user has indeed tagged it as
"to-read" with that notion in mind, but in the vast majority of cases
that isn't the case! ;-)

So representing all tagged-resource/tag relationships as statements
using the dc:subject property not only fails to capture the particular
relationship that someone had in mind when they tagged a resource, but
asserts a relationship which - in many cases - the tagger did not
intend.

(Actually, I should have highlighted yesterday that del.icio.us doesn't
only represent tags using dc:subject, it also uses the property
http://purl.org/rss/1.0/modules/taxonomy/topics from the RSS taxonomy
module. But I'd suggest that the same issue arises. Tagging is used with
intent other than to indicate a has-topic relationship.) 

So, in the general case, a property other than dc:subject (or
taxo:topic/taxo:topics) would be required. You could argue that the
dc:relation property does the job - there is some unspecified type of
relationship between the resource  and the tag - or you could argue for
a more specific "is-associated-with-tag" or "is-tagged-with" property.
I'd argue against putting "subject" in the name/URI because I think we
want to avoid suggesting (even to a human reader) any relationship with
the dc:subject property.
 
And indeed the ontology I referred to yesterday provides such a property

http://www.holygoat.co.uk/owl/redwood/0.1/tags/taggedWithTag

Described as "Indicates that the subject has been tagged with the object
tag. This does not assert by who, when, or why the tagging occurred. For
that information, use a reified Tagging resource."

So we can say

resource:A tags:taggedWithTag tag:T

The final part of that description is what I was referring to in my "but
see also note below" above. Depending on what information it is
desirable/necessary/useful to capture about the "tagging", then you may
wish to adopt the approach of describing that "event" in more detail. If
I understand it correctly, the ontology supports both the simple 

resource:A tags:taggedWithTag tag:T

approach, and it also supports a richer, more complex approach which
seeks to represent more of the "context", particularly the agent who
performed it and the point in time they did so, by representing a
"tagging event" as a resource ("reifying the tagging").

See http://www.holygoat.co.uk/projects/tags/ for more discussion,
examples.

> However, DCMI would not need to define new encoding schemes 
> on a regular basis since the above qualified Dublin Core 
> really boils down to:
> 
>  <dc:subject>
>    <rdf:Description>
>      <rdf:type rdf:resource="http://purl.org/dc/terms/MESH"/>
>      <rdf:value>D08.586.682.075.400</rdf:value>
>      <rdfs:label>Formate Dehydrogenase</rdfs:label>
>    </rdf:Description>
>  </dc:subject>
> 
> Which generates the same exact RDF triples.  This implies 
> that anybody can create new encoding schemes and semantics, 
> albeit not in the dcterms: namespace since it is controlled 
> by DCMI, and still be compatible with the DCMI model.  So if 
> Flickr wanted to define their definition of tags they could just do:
> 
>  <dc:subject>
>    <rdf:Description>
>      <rdf:type rdf:resource="http://www.flickr.com/photos/tags/"/>
>      <rdf:value>D08.586.682.075.400</rdf:value>
>      <rdfs:label>Formate Dehydrogenase</rdfs:label>
>    </rdf:Description>
>  </dc:subject>
> 
> Which would provide interoperability with Dublin Core without 
> DCMI lifting a finger.  Internally at OCLC, for research 
> projects, we have been using this interoperability practice 
> for defining new encoding schemes to controlled vocabularies 
> that DCMI has not defined.
> For example, GSAFD, NGL, RVM, etc.

Oh, yes, in terms of the name/URI for the term, I quite agree that
there's no requirement that a DCMI-owned URI is assigned. I don't mind
whether it's a DCMI-owned URI or a URI owned by another agency (as long
as it's an agency I trust to (a) manage their URIs sensibly so as to
ensure a "reasonable" degree of persistence and (b) provide consistent
representations of the identified resources in a way which makes those
representations accessible to my tools using simple widely-deployed
mechanisms in accordance with W3C guidelines.) 

But (IMHO) the requirement would not be satisfied by coining a new
vocabulary encoding scheme, whether that scheme was identified by a
DCMI-owned URI or a URI owned by another agency.

Pete