Re: Tag ontology RFC

Stefano,
   Thank you for your comments. Replies below.

> First of all, tagging is the idea of allowing people to choose their 
> own 'things' instead of relying on somebody else's concepts... and 
> here you are, defining things like
>
>  :equivalentTag
>  :relatedTag
>
> that are exactly those idealized concepts that fit your mindset but 
> might not fit mine. I suggest to remove those alltogether and let 
> ad-hoc-ontologies handle the relationships between tags. Why? well, 
> there is no difference between tag:relatedTag and a general purpose 
> RDF property anyway.

Firstly, I have been drifting towards reifying tag relations, too, as I 
think I added to that document. I am of the belief that both taggings 
and interrelationships between tags are user-centric, and so must be 
reified to capture this additional information. Danny has eloquently 
put forth a companion view, that similar goals can be accomplished by 
distinguishing between users' tags through namespaces.

Having some way to express relationships between tags is useful, I 
think. E.g. I use data from two sources, one American and one English; 
the former tags with "humor" and the latter with "humour". Someone else 
might not equate the two, but I might wish to integrate them. Various 
uses can be applied for less-strict relationships, right down to 
relatedTag (which, as you note, is pretty much synonymous with the 
existence of any property). If it's going into ad-hoc ontologies, I may 
as well make them less ad-hoc and put them on the same page, no?

> The only relationships that should be put in a tag ontology are those 
> that are objective to the tag themselves, for example "collidesWith" 
> if they share at least one label. The rest should be left to the users 
> to decide (whether they are equivalent, related, or in what kind of 
> relation they are).

I think you're solely commenting on the single-triple tag 
interrelations. Yes, I quite agree... I was of a mind to remove 
equivalentTag for that reason. However, :relatedTag can be considered 
as objective as any statement (e.g. shared tagged object = related?).

> Minor, but I think :tagName should be :name, let the namespace provide 
> the context.

Mmm.

> :taggedResource is useless: it can be easily inferred.

You mean as the inverse of tags:tag? I kept both in at this stage to 
provide an option for discussing. I can see two possible uses:

1. you're focused on a resource, and wish to tag it. tags:tag pointing 
to a reification makes most sense.
2. you're focused on a tag, or a user, and wish to model their tagging. 
The tagged resource isn't primary, so you point to it rather than from 
it.

The same applies for retrieval. Any thoughts from other interested 
parties? Which way should the Tagging <-> resource relationship point?

> Honestly, I don't think the complexity is worth the value of modelling 
> the 'act of tagging',

I would disagree with that... even if one takes the simplest kind of 
collaborative tagging, del.icio.us, exporting that database to RDF 
requires dealing with that problem. del.icio.us's database has two 
dates, an author, a resource, and a set of tags in addition to all the 
bookkeeping. Try fitting that lot in a triple :)

> but in any case I definately disagree with rss:Item rdfs:subClassOf 
> tags:Tagging .
>
> If you go down this path, pretty much any action related to add RDF to 
> something has to be a subClass of tagging.... and pretty soon you end 
> up modelling provenance, trust and all that yourself.

We (Seth Russell, Danny, and myself) had a fair amount of discussion of 
this, which led to my conclusion:
- some rss:items might be considered taggings (those that annotate a 
resource with some categories)
- but it's far from a perfect match.

I summarised this by saying "Personally, I would tend to go for the 
"tag the rss:item" approach." i.e. it's not a close enough match to 
formalise.

> There is really nothing different between tagging and adding RDF. The 
> only difference is that the inference needed to extract :collidesWith 
> is different enough that requires me to type it.
>
> Anything else is just the exact same modelling that applies to any RDF 
> creation action, so we should just build on the shoulders of those who 
> are working on provenance and trust, instead of reinventing the wheel 
> every single time.

That's quite an interesting point. In an ideal world, this work indeed 
wouldn't be necessary at all; RDF would have shipped in '99 with 
quads/named graphs/signing/WoT etc. as necessary, and we'd be able to 
simply tag a resource with some RDF and figure out when and who did the 
tagging. But we can't. RDF as it stands can't do generalised annotation 
of statements within the model.

As such, this little ontology came about with the goal of modelling the 
output of something like del.icio.us --- a system which allows _users_ 
to apply text-string tags to URIs. The complexity of the data model 
(use of reification) is rather irrelevant. To create a tag: mint a URI 
and point it to the given label (optionally language tagged). Tagging a 
resource: encode who and when, and dump them out as a few triples. The 
user interface hides the rest.

The reification is pretty handy in practice --- I've already put 
together a system that knows about related nodes through shared 
authors/tags/resources, and can do all the other stuff that one would 
expect a tagging system to do. Expecting to use provenance etc. at the 
moment wouldn't even be able to separate my tags from yours, or sort my 
taggings by date, which is unfortunate. If it could, it would be 
through using a non-standard technology like Named Graphs, Redland 
context nodes, etc.

Regards,
-R

Received on Tuesday, 5 April 2005 17:04:01 UTC