[Xesam] Details of tag handling

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Wed Jul 2 03:16:57 PDT 2008


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.

Cheers,
Mikkel


More information about the Xesam mailing list