Thanx Pete, I knew I'd read something before but couldn't find it.

Is this a key question for this community - is this something we'd need a task force for?

I'm thinking of two use cases:
1. To encode all the tags entered into my system against my set of metadata records (some of which may be user-generated themselves).  This means the date and creator should be capture-able for each.
2. To generate a "summary" record which includes user-generated tags, not for tag-level processing but to provide community-sourced access points that the original metadata record author may not have included.  Essentially saying: "these may also be useful access keywords, but they were not added by the record author, in case you want to exclude them from some searches".  These may only be selected tags, eg. most popular for that resource, those voted as popular/useful, hand-selected, etc.

As I said, I'm thinking what's important is the source/author of the main metadata vs tags.  I know in the library world (for now at least) we want the ability to adjust a search scope to "authoritative" and "community".  Within a particular system, there could also be search scopes of metadata/tag author (user) and date created.

That leads me to wonder how to encode tags where you DO know the type.  Eg. using Beckett's tag-wiki idea, you may know that tag "dog" is a subject and tag "documenty" is a type.  I can now encode those appropriately under dc:subject and dc:type, but I still want to indicate the source is not the main metadata author.  Maybe tags:subjectTag?  Or maybe a sub-description where the creator is specified:
eg 
<dc:subject>
  <tags:TagClass>
    <rdf:value>dog</rdf:value>
    <dc:creator>jonjon</dc:creator>
    <dc:created>2008-08-01</dc:created>
    <dc:isPartOf>My Application</dc:isPartOf>
  </tags:TagClass>
</dc:subject>

...here I tried to include the tagging context as dc:IsPartOf, or maybe dc:source, or maybe if the tag had a value URI it would indicate the scope?

That means we need two ways to encode tags:
a). typed tags - in well-known properties with the ability to indicate their source is external to the metadata record author
b). un-typed tags - in a separate property that is a catchall for "relevant metadata values" that are unable to be assigned to a particular property.  I guess this may also be of use to the main metadata record author too??

As for dc:description, you're right, it depends on your definition of "account".  The dictionaries seem to indicate an "account" is an explanation, usually as a statement or narrative.  I guess that's fair enough - though hows about a one-word statement, like a tag?? :-).  I was looking at the name "description" and thinking, well, all the DC properties are descriptions, so they are probably all sub-properties of dc:description.  Therefore tag could be a sub-property too.  I guess not.

So the question is: Is how to encode tags in a DC Application Profile a dilemma for the DC community that needs to be investigated.  And if so, are there other use cases besides the two above.

Thanx,
Douglas


>>> Pete Johnston <[log in to unmask]> 31/07/08 21:54 >>>
Douglas,

Have you seen Richard Newman's Tag Ontology [1], which I mentioned back
at [2]?

It's a while since I looked at it, but I think it covers much of what
you propose.

It supports two approaches, I think

(i) using a tags:taggedWithTag property to relate the described resource
to the tag-as-resource (much as you suggest, I think)

(ii) a slightly richer/more complex approach which models a relationship
between the described resource and a "tagging" as an event (using a
different property tags:tag), with that tagging-as-event in turn related
to a tag-as-resource (and an agent and a date/time). That approach is
rather neat because it allows you to capture a lot of information about
the "context" of the tagging: it was done by Douglas yesterday morning
etc 

I agree with you that the thing-tag relationship is not a subpropery of
dc:subject because a tag doesn't always indicate "topic". But I'd also
be reluctant to say the thing-tag relationship (e.g. tags:taggedWithTag
in (i) or some alternative property) is a subproperty of dc:description.


I say that because I don't think a tag necessarily provides "An account
of the resource". It all depends what "account" means and what a "tag"
is, I suppose! :-) But given that people provide tags for concepts as
diverse as "resource type" (video, article etc), "level of
interestingness", or things like "on my to-read list" or "on my to blog
about list", I'm not convinced all of these are "accounts of the
resource". 

But that's OK - we don't _have_ to make properties subproperties of
DCMI-owned properties, and it's still useful to have the relationships
that the Tag Ontology provides. I suppose if you really wanted to, you
could argue it's a subproperty of dc:relation, but I'm not sure that's
particularly useful because a use of the dc:relation property tells me
so little. 

Pete

[1] http://www.holygoat.co.uk/projects/tags/ 
[2]
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0611&L=DC-SOCIAL-TAGGIN 
G&T=0&F=&S=&P=435

---
Pete Johnston
Technical Researcher, Eduserv Foundation
[log in to unmask] 
+44 (0)1225 474323
http://www.eduserv.org.uk/foundation/ 
http://efoundations.typepad.com/efoundations/