[Xesam] Details of tag handling

[Mikkel Kamstrup Erlandsen]

2008/7/2 Sebastian Trüg <strueg at mandriva.com>:
> On Wednesday 02 July 2008 12:16:57 Mikkel Kamstrup Erlandsen wrote:
>> 2008/7/2 Sebastian Trüg <strueg at mandriva.com>:
>> > While this is easy to query it is not very clean semantically speaking
>> > since you link tag objects and tagged resources via string literals. In
>> > Nepomuk we use tag objects and relate tagged resources to the URI of this
>> > object.
>> >
>> > - Querying objects on their tags is also simple: just get all resources
>> > that are related to the tag via the tagging property.
>> > - Getting a list of all tags is as easy as before: list all resources of
>> > type xesam:Tag (or nao:Tag in Nepomuk)
>> > - Querying all files without a tag is also simple (in sparql we use a
>> > filter) - listing all files with their associated tag's names is also not
>> > a big deal (a sparql query can easily be extended or one fetches tags and
>> > their labels for each file separately)
>> > - renaming of tags is much simpler than your method: only change one!
>> >  property: the tag's label (in your version all tagged files have to be
>> >  updated.
>> > - deleting a tag is as simple as deleting the tag resource and all
>> > triples referencing it.
>> > - having tags without files is trivial: tag resources can live on their
>> > own anyway.
>> >
>> > Hope this helps a bit. Keep in mind that with tag resources we leave the
>> > world of two-dimensional metadata which can be handled by databases like
>> > lucene.
>>
>> That is the problem. However for tags specifically it may not be a
>> problem. If we can assume that users don't carry around tonnes of tags
>> at least. The application can first fetch a list of all Tag objects
>> and create a tag_name<->uri map.Then search for items with the
>> particular uri when the user requests some tagged items. As said this
>> does not scale very well.
>>
>> This could be remedied by having a convention on how to construct tag
>> uris. For example tag://<tag_name> or something more elaborate.
>>
>> So; bottom line - I am not as such opposed to using proper uri
>> relations for tags. We just need to agree on hot to do it.
>
> The way I see it, the problem is: do we introduce triples into Xesam at this
> level or not, right?
> Because with triples it is easy (as already done in Nepomuk). But without
> plain strings are way simpler. The question is: do we want some hybrid
> solution which may be an overhead for both worlds.

(This thread is item 6 on http://xesam.org/main/XesamUpdates)

The more I think about this, the more I think the answer is "yes". I
do not object to the term "hybrid", but I actually still think the
approach is fairly clean (considering that Xesam utilizes a field
based data model).

So to rehash:

 * xesam:userKeywords stores a list of _opaque_ tag:// uris
 * Applications wanting to query tags first have to resolve tag-name
-> tag-uri however it prefer (on-the-fly or precomputed map)
 * This gives incredible flexibility compared to a flat list of tag
names stuffed in xesam:userKeywords. Flexibility both for the server
and client

That's my opinion anyway. Do chime in.

Cheers,
Mikkel

-- 
Cheers,
Mikkel