Unified system for tags

[Vidar Ramdal <vi...@idium.no>]

These are just some loose thoughts that have been brewing in my mind
lately, after reading Richardson/Ruby: RESTful Web Services [1].

In order to make Sling (even) more buzzword compliant, I have been
thinking about a system for tags. Yes, I'm talking about those
keywords that you label your bookmarks with on del.icio.us, photos on
Flickr and so on.

Of course, a tag could just be a (multi-value) string property on a
node. But a tag could also be considered to be a resource in its own
right, with its own URL (e.g. /tags/<tagname>).  (The concept of tags
as resources is very much present in [1]).

Accessing a tag's URL would output nodes that have the given tag. The
list could of course be rendered in different formats (json, xml,
etc).  Accessing /tags would give a list of tags that are in use. That
list would be useful when a user is applying tags to nodes (in
auto-complete fields etc).

In its simplest form, this could be implemented with a servlet or two.
But, Sling being a WEB framework, maybe tags should be a more
integrated part of the framework. In what way, though, I'm not sure.
Perhaps we could do some tricks with indexing or observation, so that
retrieving a tag (and its resources) could be speedier.

As I hope I made clear, this is not something I've thought through in
any way, and I'm not even sure if it's such a generic usecase that it
should be included in Sling - maybe it's just specific to certain
applications.

WDYT?

[1] http://oreilly.com/catalog/9780596529260/
-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070

Re: Unified system for tags

[Felix Meschberger <fm...@gmail.com>]

Hi Vidar,

We have implemented such a feature exactly as you describe it in our
Communiqué 5 product and incidentally, Betrand Delacretaz just yesterday
wrote an informative blog entry about it [2]

Regards
Felix

[2] http://dev.day.com/microsling/content/blogs/main/cq5tags.html

Vidar Ramdal schrieb:
> These are just some loose thoughts that have been brewing in my mind
> lately, after reading Richardson/Ruby: RESTful Web Services [1].
> 
> In order to make Sling (even) more buzzword compliant, I have been
> thinking about a system for tags. Yes, I'm talking about those
> keywords that you label your bookmarks with on del.icio.us, photos on
> Flickr and so on.
> 
> Of course, a tag could just be a (multi-value) string property on a
> node. But a tag could also be considered to be a resource in its own
> right, with its own URL (e.g. /tags/<tagname>).  (The concept of tags
> as resources is very much present in [1]).
> 
> Accessing a tag's URL would output nodes that have the given tag. The
> list could of course be rendered in different formats (json, xml,
> etc).  Accessing /tags would give a list of tags that are in use. That
> list would be useful when a user is applying tags to nodes (in
> auto-complete fields etc).
> 
> In its simplest form, this could be implemented with a servlet or two.
> But, Sling being a WEB framework, maybe tags should be a more
> integrated part of the framework. In what way, though, I'm not sure.
> Perhaps we could do some tricks with indexing or observation, so that
> retrieving a tag (and its resources) could be speedier.
> 
> As I hope I made clear, this is not something I've thought through in
> any way, and I'm not even sure if it's such a generic usecase that it
> should be included in Sling - maybe it's just specific to certain
> applications.
> 
> WDYT?
> 
> [1] http://oreilly.com/catalog/9780596529260/

Re: Unified system for tags

[Alexander Klimetschek <ak...@day.com>]

On Fri, Apr 24, 2009 at 3:03 PM, Vidar Ramdal <vi...@idium.no> wrote:
> For a start, the bundle could contain this:
>
> - Script/servlet for retrieving a tag's meta-info (/tags/tagname)
> (at least as an example - users would want to create their own script)
>
> - Script/servlet for retrieving content tagged with a certain tag
> (/tags/tagname.list)
> (same as above)
>
> - Script/servlet for deleting a tag
> When a tag is deleted, it should be removed from all nodes that uses it
>
> - PostProcessor for adding tags
> This could work like this: The postprocessor monitors POSTs, and
> checks if a "tags" property is modified. If the "tags" property
> contains a new tag (a tag that does not yet exist under /tags), it is
> created there.

You can also do this as a JCR observation listener. This will then
ensure consistency of the tags property for JCR API clients as well,
not only Sling HTTP clients. You have to think about duplicates and
deleted tags as well.

Regarding creation: it is also necessary to check write permissions
before creating a tag, this might require two requests for a smooth
user interface (no exceptions on write). This is the drawback of the
implicit relation between content and the tag tree.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Unified system for tags

[Vidar Ramdal <vi...@idium.no>]

2009/4/23 Vidar Ramdal <vi...@idium.no>:
> These are just some loose thoughts that have been brewing in my mind
> lately, after reading Richardson/Ruby: RESTful Web Services [1].
>
> In order to make Sling (even) more buzzword compliant, I have been
> thinking about a system for tags.

> 2009/4/24 Juan José Vázquez Delgado <ju...@gmail.com>:
>> ...That is a nice feature but IMHO is more suitable for specific use
>> cases, such as CMS systems, than for Sling itself....

2009/4/24 Bertrand Delacretaz <bd...@apache.org>:
> IMHO that shouldn't prevent implementing it under contrib - not all
> Sling users will need it, but using Sling for CMSish apps is certainly
> a common use case.

Certainly, this could be a bundle supplied under contrib.

For a start, the bundle could contain this:

- Script/servlet for retrieving a tag's meta-info (/tags/tagname)
(at least as an example - users would want to create their own script)

- Script/servlet for retrieving content tagged with a certain tag
(/tags/tagname.list)
(same as above)

- Script/servlet for deleting a tag
When a tag is deleted, it should be removed from all nodes that uses it

- PostProcessor for adding tags
This could work like this: The postprocessor monitors POSTs, and
checks if a "tags" property is modified. If the "tags" property
contains a new tag (a tag that does not yet exist under /tags), it is
created there.

Does this sound as a reasonable approach?

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070

Re: Unified system for tags

[Juan José Vázquez Delgado <ju...@gmail.com>]

>> ...That is a nice feature but IMHO is more suitable for specific use
>> cases, such as CMS systems, than for Sling itself....
>
> IMHO that shouldn't prevent implementing it under contrib - not all
> Sling users will need it, but using Sling for CMSish apps is certainly
> a common use case.

Yep, you´re right. Contrib can be a good place for that kind of stuff.
Anyway, tagging is a cool feature. +1 then.

Juanjo.

Re: Unified system for tags

[Bertrand Delacretaz <bd...@apache.org>]

2009/4/24 Juan José Vázquez Delgado <ju...@gmail.com>:
> ...That is a nice feature but IMHO is more suitable for specific use
> cases, such as CMS systems, than for Sling itself....

IMHO that shouldn't prevent implementing it under contrib - not all
Sling users will need it, but using Sling for CMSish apps is certainly
a common use case.

-Bertrand

Re: Unified system for tags

[Juan José Vázquez Delgado <ju...@gmail.com>]

Hi VIdar,

> As I hope I made clear, this is not something I've thought through in
> any way, and I'm not even sure if it's such a generic usecase that it
> should be included in Sling - maybe it's just specific to certain
> applications.
>
> WDYT?

That is a nice feature but IMHO is more suitable for specific use
cases, such as CMS systems, than for Sling itself.

BR,

Juanjo.

Re: Unified system for tags

[Alexander Klimetschek <ak...@day.com>]

On Fri, Apr 24, 2009 at 9:37 AM, Vidar Ramdal <vi...@idium.no> wrote:
> There's one thing: It might be useful to let a tag (or a set of tags)
> only be available for a certain branch of the resource tree.
> Especially if a repository is hosting content for several independent
> websites, you'd want each website to have its own tags tree.
> Do you handle that in CQ5 - if so, how?

You can configure the tag editing field, where you assign tags to a
page, to only allow the use of a certain tag namespace (eg.
/etc/tags/mysitenamespace). We found it overkill to put such specific
constraints (they'll change from one customer to the other) directly
into the content model.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Unified system for tags

[Vidar Ramdal <vi...@idium.no>]

> On Thu, Apr 23, 2009 at 10:16 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>... In order to make Sling (even) more buzzword compliant, I have been
>> thinking about a system for tags. [...]

2009/4/24 Bertrand Delacretaz <bd...@apache.org>:
> Sounds good, and as Felix says I just wrote a blog entry about this
> yesterday [2]. [...]

OK, I'm subscribing to your blog. From now on. Promise.

>> ...Accessing a tag's URL would output nodes that have the given tag. The
>> list could of course be rendered in different formats (json, xml,
>> etc)....
>
> Good idea, but maybe with a specific selector? [...]

True.

>> [...] But, Sling being a WEB framework, maybe tags should be a more
>> integrated part of the framework....

> I agree with Juanjo, that a tagging system is not a core component.
> And I agree with you that it's a common use case, so contrib is
> probably the place? The tagging system would then be one or several
> bundles, servlets, observation components if needed, etc.

Sounds good.

There's one thing: It might be useful to let a tag (or a set of tags)
only be available for a certain branch of the resource tree.
Especially if a repository is hosting content for several independent
websites, you'd want each website to have its own tags tree.
Do you handle that in CQ5 - if so, how?

> [1] http://oreilly.com/catalog/9780596529260/
> [2] http://dev.day.com/microsling/content/blogs/main/cq5tags.html
>



-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070

Re: Unified system for tags

[Juan José Vázquez Delgado <ju...@gmail.com>]

> It's a drawback, but we feel the advantages (content agility) outweigh
> the drawbacks (need to handle some rare stuff at the application
> level).

Pros vs cons. Ok, good!.

Juanjo.

Re: Unified system for tags

[Juan José Vázquez Delgado <ju...@gmail.com>]

Interesting approach. Good enough from my pont of view.

BR,

Juanjo.

On Fri, Apr 24, 2009 at 7:26 PM, Alexander Klimetschek <ak...@day.com> wrote:
> On Fri, Apr 24, 2009 at 6:32 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> 2009/4/24 Juan José Vázquez Delgado <ju...@gmail.com>:
>>>> ...See also rule 5 of David's model [2].
>>>
>>> Right, but if tags are deleted or their names modified you´re forced
>>> to search the path tag properties over all the repository and fix the
>>> affected nodes. It seems an important drawback. WDYT?...
>>
>> It's a drawback, but we feel the advantages (content agility) outweigh
>> the drawbacks (need to handle some rare stuff at the application
>> level).
>
> Right. We are doing this in a "lazy" way through the use of an
> observation listener for the "tags" property on the content. Whenever
> this is changed, which can happen much later than the modification of
> the tag tree at /etc/tags, it is validated against the defined tags
> under /etc/tags. When reading the tags property, there is an
> application-level utility that filters out non-existing tag.
>
> We are also planning to use this lazy approach for restructuration of
> tags, eg. moving or merging. This also solves the conceptual problem
> of two very different permission areas: tag administration and content
> editing.
>
> Ok, that's enough of the details ;-)
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>

Re: Unified system for tags

[Alexander Klimetschek <ak...@day.com>]

On Fri, Apr 24, 2009 at 6:32 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> 2009/4/24 Juan José Vázquez Delgado <ju...@gmail.com>:
>>> ...See also rule 5 of David's model [2].
>>
>> Right, but if tags are deleted or their names modified you´re forced
>> to search the path tag properties over all the repository and fix the
>> affected nodes. It seems an important drawback. WDYT?...
>
> It's a drawback, but we feel the advantages (content agility) outweigh
> the drawbacks (need to handle some rare stuff at the application
> level).

Right. We are doing this in a "lazy" way through the use of an
observation listener for the "tags" property on the content. Whenever
this is changed, which can happen much later than the modification of
the tag tree at /etc/tags, it is validated against the defined tags
under /etc/tags. When reading the tags property, there is an
application-level utility that filters out non-existing tag.

We are also planning to use this lazy approach for restructuration of
tags, eg. moving or merging. This also solves the conceptual problem
of two very different permission areas: tag administration and content
editing.

Ok, that's enough of the details ;-)

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Unified system for tags

[Bertrand Delacretaz <bd...@apache.org>]

2009/4/24 Juan José Vázquez Delgado <ju...@gmail.com>:
>> ...See also rule 5 of David's model [2].
>
> Right, but if tags are deleted or their names modified you´re forced
> to search the path tag properties over all the repository and fix the
> affected nodes. It seems an important drawback. WDYT?...

It's a drawback, but we feel the advantages (content agility) outweigh
the drawbacks (need to handle some rare stuff at the application
level).

-Bertrand

Re: Unified system for tags

[Juan José Vázquez Delgado <ju...@gmail.com>]

> Because references a) don't scale at the moment with Jackrabbit

Is this a core design constraint or intended to be improved in future
Jackrabbit releases?.

> and b) hard references make your content very unflexible regarding partial
> copying etc. As Bertrand explains it in his post [1]:
>
> <snip>
> We don't use JCR references, but simply store paths in properties, as
> this gives us more flexibility when restructuring things. It's hard to
> say what will happen to those tags, and to the very concept of
> tagging, over the expected lifetime of our product, so we accept
> potentially dangling references (and cope with them at the application
> level) to gain content agility.
> </snip>
>
> See also rule 5 of David's model [2].

Right, but if tags are deleted or their names modified you´re forced
to search the path tag properties over all the repository and fix the
affected nodes. It seems an important drawback. WDYT?

> [1] http://dev.day.com/microsling/content/blogs/main/cq5tags.html
> [2] http://wiki.apache.org/jackrabbit/DavidsModel

Re: Unified system for tags

[Alexander Klimetschek <ak...@day.com>]

2009/4/24 Juan José Vázquez Delgado <ju...@gmail.com>:
>> Sounds good, and as Felix says I just wrote a blog entry about this
>> yesterday [2]. From that you can see that in Day's cq5 the tags are a
>> hierarchy of nodes under /etc/tags, with a specific node type, so a
>> tag is indeed a separate resource.
>
> Bertrand, just a question. You decided not to use references pointing
> to tags. Why?. I say this because, in principle, using references
> looks a good design.

Because references a) don't scale at the moment with Jackrabbit and b)
hard references make your content very unflexible regarding partial
copying etc. As Bertrand explains it in his post [1]:

<snip>
We don't use JCR references, but simply store paths in properties, as
this gives us more flexibility when restructuring things. It's hard to
say what will happen to those tags, and to the very concept of
tagging, over the expected lifetime of our product, so we accept
potentially dangling references (and cope with them at the application
level) to gain content agility.
</snip>

See also rule 5 of David's model [2].

[1] http://dev.day.com/microsling/content/blogs/main/cq5tags.html
[2] http://wiki.apache.org/jackrabbit/DavidsModel

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Unified system for tags

[Juan José Vázquez Delgado <ju...@gmail.com>]

> Sounds good, and as Felix says I just wrote a blog entry about this
> yesterday [2]. From that you can see that in Day's cq5 the tags are a
> hierarchy of nodes under /etc/tags, with a specific node type, so a
> tag is indeed a separate resource.

Bertrand, just a question. You decided not to use references pointing
to tags. Why?. I say this because, in principle, using references
looks a good design.

Juanjo.

> [2] http://dev.day.com/microsling/content/blogs/main/cq5tags.html

Re: Unified system for tags

[Bertrand Delacretaz <bd...@apache.org>]

Hi Vidar,

On Thu, Apr 23, 2009 at 10:16 PM, Vidar Ramdal <vi...@idium.no> wrote:
> These are just some loose thoughts that have been brewing in my mind
> lately, after reading Richardson/Ruby: RESTful Web Services [1].

Good choice ;-)

>... In order to make Sling (even) more buzzword compliant, I have been
> thinking about a system for tags. Yes, I'm talking about those
> keywords that you label your bookmarks with on del.icio.us, photos on
> Flickr and so on.
>
> Of course, a tag could just be a (multi-value) string property on a
> node. But a tag could also be considered to be a resource in its own
> right, with its own URL (e.g. /tags/<tagname>).  (The concept of tags
> as resources is very much present in [1]).

Sounds good, and as Felix says I just wrote a blog entry about this
yesterday [2]. From that you can see that in Day's cq5 the tags are a
hierarchy of nodes under /etc/tags, with a specific node type, so a
tag is indeed a separate resource.

> ...Accessing a tag's URL would output nodes that have the given tag. The
> list could of course be rendered in different formats (json, xml,
> etc)....

Good idea, but maybe with a specific selector? You can argue that
accessing a tag directly should return it, for example

  /etc/tags/mynamespace/mycategory/mytag.tidy.json

would return info about the tag itself, whereas

  /etc/tags/mynamespace/mycategory/mytag.items.json

would return links to items tagged with "mytag".

>  Accessing /tags would give a list of tags that are in use. That
> list would be useful when a user is applying tags to nodes (in
> auto-complete fields etc).

Sounds good. In cq5 this is also used to manage the tags, change their
titles or descriptions, etc.

> ...In its simplest form, this could be implemented with a servlet or two.
> But, Sling being a WEB framework, maybe tags should be a more
> integrated part of the framework....

I agree with Juanjo, that a tagging system is not a core component.
And I agree with you that it's a common use case, so contrib is
probably the place? The tagging system would then be one or several
bundles, servlets, observation components if needed, etc.

-Bertrand

[1] http://oreilly.com/catalog/9780596529260/
[2] http://dev.day.com/microsling/content/blogs/main/cq5tags.html