2008/7/2 Sebastian Trüg <[EMAIL PROTECTED]>: > On Wednesday 02 July 2008 12:16:57 Mikkel Kamstrup Erlandsen wrote: >> 2008/7/2 Sebastian Trüg <[EMAIL PROTECTED]>: >> > 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 _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
