Tag ontology design

The goal of this ontology is to model the relationship between an agent, an arbitrary resource, and one or more tags. This relationship is embodied in one or more taggings, which are temporal events associating the actors.

Further discussion, and pertinent links to W3C list emails, can be found in this blog post.

The ontology itself can be found in RDF/XML and in Notation-3 formats.

Updated: 2005-03-29.

Brief update, 2005-09-27: this ontology is now being used in actual working software. In other words — it works.

Update, 2005-12-03: added an example.

Update, 2005-12-21: moved deprecated HTML Notation 3 version to a separate page. Example enhanced.

Modelling questions

Besides modelling the tagging relationship, modelling tags is itself a challenge. Simple literals are inadequate — e.g., we cannot use them as subjects of triples. Instead, I suggest that tags are modelled through URIs1. This seems to agree with some other usages; e.g. WordNet, SKOS, Annotea…?

Seth Russell expressed an interest in modelling synsets. Clearly (thanks to the ambiguity of tags themselves) this must be a subjective relation between tags, which ought to be reified to include the person asserting the relation.

Fundamental design

The fundamental design decisions so far are thus:

  1. Taggers are foaf:Agents.
  2. Taggings reify the n-ary relationship between a tagger, a tag, a resource, and a date. Relationships exist for each of these roles.
  3. Tags are members of a Tag class. Tags have names. We do not attempt to implement plurals (as in the labels schema) or synonymity at this stage, as these are subjective assessments of a tag2.

Relation to rss:item

As Seth Russell pointed out, there is some kind of relationship between a Tagging and an rss:item. The latter relates an author, a title, a description, and arbitrary additional elements (which may include categories/tags/subjects). The RSS item (defined by the RSS1.1 specification as a discrete content instance) typically relates blog posts to categories and the author of the post. Categorisation is usually achieved by use of dc:subject or similar relationships. A Tagging, by contrast, explicitly relates a resource to some tags; it is a reification of a relationship, not a "discrete content instance" with some attributes.

Examples

Consider the following RDF fragments:

RSS item
<http://example.com/blog/post/1> a rss:item ;
  rss:title "My first blog post"@en ;
  rss:description "Some body text."@en ;
  rss:link <http://example.com/blog/post/1> ;
  dc:creator "Richard Newman" ;
  dc:subject "blog", "chimpanzee" .
Tagging
<http://example.com/blog/post/1> :tag
 [ a :Tagging ;
   :associatedTag tag:blog, tag:chimpanzee ;
   :taggedBy <http://example.com/People/Jim> ;
   :taggedOn "2005-03-29T15:24:10Z"^^xsd:date ] .
 tag:blog :tagName "blog" .
 tag:chimpanzee :tagName "chimpanzee" ;
 :relatedTag tag:monkey .       # should be reified!

Explanation

The former says that /blog/post/1 is a discrete content item with a certain title and description. There is a link to the item on the Web, and some non-standard literal annotations for the creator and the subject. Its sole subject annotation power is linking the item itself to a subject or taxonomic entry due to the use of dc:subject. There is only an implicit suggestion of who decided on the subjects, when they were decided, etc.

The latter tags /blog/post/1 with some uniquely-identifiable tags, defining who did the tagging and when the tagging occurred. It appears to be completely separate from the definition of the item; indeed, it would be fine to combine these two fragments, rendering obsolete the dc:subject relations on the rss:item.

Alternatively, we could smush the two together:

Combined approach
<http://example.com/blog/post/1> a tags:Tagging, rss:item ;
   rss:title "My first blog post"@en ;
   rss:description "Some body text."@en ;
   rss:link <http://example.com/blog/post/1> ;
   tags:associatedTag tag:blog, tag:chimpanzee ;
   tags:taggedBy <http://example.com/People/Jim> ;
   tags:taggedResource <http://example.com/blog/post/1> ;
   tags:taggedOn "2005-03-29T15:24:10Z"^^xsd:date ] .

The only problem with this is that the post is tagging itself, which is incorrect. Using a blank node for the rss:item would fix this.

The author's opinion, the role of inference

Personally, I would tend to go for the "tag the rss:item" approach. This keeps the tagging separate, allowing other people to seamlessly tag your posts; furthermore, through the following annotations

rss:Item rdfs:subClassOf tags:Tagging .
rss:category rdfs:subPropertyOf tags:associatedPlainTextTag .
rss:pubDate rdfs:subPropertyOf tags:taggedOn .
rss:link rdfs:subPropertyOf tags:taggedResource .

inference can turn items into Taggings whenever we consider it appropriate (e.g. from del.icio.us's feeds). Relating the two at a basic level leads to problems.

Semantics and subclassing

We can't make a Tagging a subclass of item — items MUST have a title and link, and not every tagging event has a title! There are also uncomfortable semantics associated with what an item is, what the link means, etc.

However, we also can't make a general item a subclass of Tagging, because not every item is annotated with a category, and furthermore generators are encouraged to make the link element point to the URI of the item (i.e. you annotate an actual dereferenceable blog post, and the link just echoes this). This makes the whole thing meaningless, as the item is just tagging itself.

We could conceive of a “link list” item which is a Tagging and an item, but it's not clear what benefits this would bring.

Relationships between tags

It is desirable to provide some way to interrelate tags; e.g. to describe synonymity, or more human relations like simple association. Of course, these relations are not absolute; stating 

tag:ruby :relatedTag tag:gemstone

will be useless or wrong to a significant proportion of users. more accurate is to reify:

_:x      a      :TagRelation ;
  rdf:subject   tag:ruby ;
  rdf:object    tag:programming ;
  rdf:predicate skos:broader ;
  :relater      ex:Richard .
_:y      a      :TagRelation ;
  rdf:subject   tag:ruby ;
  rdf:object    tag:gemstone ;
  rdf:predicate :relatedTag ;
  :relater      ex:John .

These terms are experimental, and there are probably better ways to do this, but you get the idea.

Note, of course, that this vocabulary does nothing to stop you tagging tags…

Example

As an example, we will model the resource ex:post as being tagged with two tags, labelled “great” and “interesting” respectively. I have largely omitted type information, though it can be added if desired.

Basic, anonymous tagging, not assigning URIs to tags:

ex:post tags:taggedWithTag [ tags:tagName "great" ] , 
                           [ tags:tagName "interesting" ] .

Using a tag namespace to allow for repeated references to the same tag (not just different tags with the same label):

ex:post tags:taggedWithTag tag:great , tag:interesting .
# Label the tags — once is enough.
tag:great a tags:Tag ;
          tags:tagName "great" .
tag:interesting a tags:Tag ;
                tags:tagName "interesting" .

Remembering that tags are resources, so we can use the raw URIs if we wish:

ex:post tags:taggedWithTag 
  <http://www.holygoat.co.uk/owl/redwood/tag/great> , 
  <http://www.holygoat.co.uk/owl/redwood/tag/interesting> .
# Label the tags — once is enough.
tag:great a tags:Tag ;
          tags:tagName "great" .
tag:interesting a tags:Tag ;
                tags:tagName "interesting" .

Reified tagging, minimal information. This says that at some point somebody tagged ex:post with these two tags, but we don't know when or who.

ex:post tags:tag [ tags:associatedTag tag:great , 
                                      tag:interesting ] .

Whole-hog, with anonymous Tagging:

ex:post tags:tag [ tags:associatedTag tag:great , 
                                      tag:interesting ;
                   tags:taggedBy [ foaf:mbox <mailto:r@example.com> ] ;
                   tags:taggedOn "2005-12-03T21:15:00.000Z"^^xsd:dateTime ] .

With an identified Tagging event, so we can refer to the event itself in future:

ex:post tags:tag tagging:abcde .
tagging:abcde a tags:Tagging ;
              tags:associatedTag tag:great , 
                                 tag:interesting ;
              tags:taggedBy [ foaf:mbox <mailto:r@example.com> ] ;
              tags:taggedOn "2005-12-03T21:15:00.000Z"^^xsd:dateTime .

1 which can be hidden: by restricting tags to one namespace (one such example namespace is <http://www.holygoat.co.uk/owl/redwood/tag/>, but del.icio.us provides another), a user interface can hide the complexity of a URI-based system.

2 not that this is necessarily a bad thing, or exclusive — after all, tags are URIs, so the tagger could well have total control. However, we may wish to relate one user's tag to another. This is an interaction which is very similar to a tagging…