How to emulate a "favorites list" with semantic data - is there a better way?

[najevi]

For the past several days I've been slowly but surely figuring out how
to emulate something that resembles the classic "Add to my favorites"
and "Remove from my favorites" links for wiki articles using semantic
data. After some long and quite spells at IRC #semanticmediawiki,
today I learned about this SF mailing list so I am polling you all to
find out if anybody recognizes the same (or similar) design goal and
can offer me some advice.

Overview:
I am planning for a collection of wiki articles describing "skins" for
each of several "boat" models. Those skinned boats are raced on
"tracks" which also have there own wiki articles describing each
track. So I will have:
3 categories of wiki articles: {Boats, Skins, Tracks}
3 templates: Template:Skin, Template:Boat, Template:Track
which are used, respectively, by:
3 forms: Form:Skin, Form:Boat, Form:Track
all to facilitate the creating of each type of wiki article. That was
the easy part!

Each visitor to the wiki has their own personal favorites and would
like to bookmark/tag/record those favorites for later query.

* The wiki hosting service is Wikia and they happen to have a 5
star article rating system which does seem to store each user's
personal 1..5 rating score for a page in a list ... however, that does
not appear to be linked in any way to semantic data or semantic
queries. (I am reasonably certain this is a dead end - but I mention
it just in case someone reading this knows better.)

My current best effort
So here's what I've been able to do with semantic data and later on
I'll describe where I get stuck. The core of my current best solution
is that each wiki article has obfuscated semantic data in the form of
a comma-delimited list of users who have marked that article as one of
ther favorite articles. (Am I going to run into some limit as to how
many strings can be in that comma delimited list?)

To manipulate that list of usernames, I define 3 properties:
Property:Favored by [[has type:string]] (this will become the list of
users who have marked the current page as a favorite)
Property:This user [[has type:string]]
Property:Operation [[has type:string]] [[allows value::Add]] [[allows
value::Remove]]
and 1 template:
Template:Favorites
which is used by
Form:Favorites

Form:Favorites is a partial form designed to manipulate only the 3
properties listed above. Notice that all other content is hidden even
the Favored by list identified above. viz:

{{{info|partial form|edit title=Manage your favorites}}}
{{{for template|Favorites|label=Add/Remove this page to/from your
favorites}}}
{{{field|Favoredby|hidden}}}
{{{field|Thisuser|default=current user|hidden}}}
;Add or remove current user? : {{{field|Operation|radiobutton|
default=Remove|mandatory}}}
{{{end template}}}

{{{standard input|free text|hidden}}}

{{{standard input|summary|preload=Form:Favorites/Preloads/
summary}}}
{{{standard input|save|label=Confirm}}} {{{standard input|
cancel}}}


The first sticking point is this. Intuitively I'd prefer to be
specifying {{{field|Thisuser|preload=current user}}} rather than
default=current user but it seems that partial form with preload at
the field parameter level is not available by design. I think this is
one great example where you really do want the existing value of This
user to be overwritten by the argument to a preload parameter. I think
my workaround for this is satisfactory (see below).

The second sticking point is that the radiobutton parameter is not
producing the expected toggling pair of radio buttons for user input.
With all other fields in Form:Favorites hidden/obfuscated this simple
Add/Remove binary choice should be the only decision a browsing user
is required to make.

A third (but minor) snafu is my use of |preload=Form:Favorites/
Preloads/summary
It just does not seem to be behaving as described at
http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Form_markup_language

Template:Favorites does the clever work of silently adding or removing
the current username to/from a comma-delimited list of usernames.
viz.

{{#switch: {{#lc: {{{Operation|}}} }}
| add = {{#arraymap:{{{Favoredby|}}}|,|x|{{#set:Is a favorite
of=x}} }} {{#set:Is a favorite of={{{Thisuser|}}} }}
| remove = {{#arraymap:{{#replace:{{#arraymap:
{{{Favoredby|}}}|,|!|{{#switch:{{{Thisuser|}}}=|!}}}}|, ,|,}} |,|x|
{{#set:Is a favorite of=x}} }}
| #default = {{#arraymap:{{{Favoredby|}}}|,|x|{{#set:Is a favorite
of=x}} }}</includeonly>
}}
{{#set:Operation={{{Operation|remove}}} }}
{{#set:This user=}}


(If the http://www.mediawiki.org/wiki/Extension:ArrayExtension was
installed at Wikia then the above would be much more elegantly
implemented using #ArrayUnion: and #ArrayDiff:)

The aforementioned workaround that makes |default=current user
deliver what |preload=current user might have delivered is that very
last line that leaves This user with a null value. Without that null
value the |default=current user parameter does not behave with the
preload effect that I wanted.

Finally, access to this partial form is created within Template:Skin,
Template:Boat, Template:Track via the line:

[[Special:EditData/Favorites/{{PAGENAME}}|Manage your favorites]]


Where I need help
The above solution is functioning fine but it is singularly clumsy
that the user is presented with a text input box in which to type
either Add or Remove when a binary pair of radiobuttons is prescribed.
If someone can help me fix that anomaly then I'll be most grateful.
The above test case can be examined at http://smwtest.wikia.com/wiki/Form:Skin
however, I am working on it at the present time so the code you see
there may not reflect what you have just read above and of course, in
the weeks ahead, it may be erased altogether.

There may be a better way to implement this "Manage my favorites"
feature so if you have solved this problem differently then please
share it here.

[Yaron Koren]

I have to admit, I'm not a fan of using SMW and SF for social-networking-type features like favorites, forums, ratings, etc. The semantic content of a page should reflect information in the real world, not wiki-specific information, in my opinion (although the "Modification date" special property in SMW already breaks that).

In any case - wow, I'm impressed by what you've accomplished. For the problem with the radiobutton not showing up - it sounds like the form can't figure out the corresponding property from the template, which isn't too surprising. If you add "|property=Operation" to the field declaration in the form, it should work. For the other issues - what's the difference (to you) between "default=" and "preload="?

-Yaron

[Bernhard Krabina]

> I have to admit, I'm not a fan of using SMW and SF for
> social-networking-type features like favorites, forums, ratings, etc. The
> semantic content of a page should reflect information in the real world, not
> wiki-specific information

This is something I really don't understand. Why is the information,
which person likes a page in the wiki or how many rate it top not
"real world" information? I've been looking for a possibility to do
ratings with semantic annotations for a long time, I also think the
existing solutions are not very advanced (because they are lacking
semantics).

Wouldn't it be great to be able to perform an ask query for pages in a
wiki with a property = something and a rating of 4 or higher? Semantic
wikis can be used so elegantly to provide directories of all kinds,
why not incorporate users written reviews (could be done on discussion
pages) and user ratings? Web 2.0 can be so interesting, but the user
generated content does not always have to be a full article, but maybe
a quick rating. Semantic forms are great, but not everybody is willing
to provide a full article, but users can be drawn to leave some
feedback which is in my opinion a very interesting real world
information.

I'd really love to see some semantically annotated social-networking
features on wikis! Maybe a Semantic Ajax Rating extension?
-Bernhard

[Bernhard Krabina]

by the way, I think "Modification date" is a great property, my vote
goes for more of such built in properties, e. g. "Number of views",
"Number of revisions"....

:-)

[Yaron Koren]

Well, I should have been more precise in my statement, since features like ratings can cover a wide variety of uses. On the one hand, you can have users expressing what activities and such they're interested in, and having that recorded on their user pages. That's an expression of real-world information, and it's totally appropriate to store such data semantically - that's how ardorado.com works, for instance. On the other extreme, there's "I found this help page useful/not useful". That's purely wiki-based information, and I think part of the reason I'm against storing it semantically is that I just don't think it makes that much sense in wikis in general, semantic or otherwise. Given that articles are changing all the time, how helpful is it to know that someone gave an article a certain rating six months ago? In addition, if someone's unhappy with a page, giving it a low rating is pretty much the least helpful thing they can do - ideally, they should try to improve the page, but even if they don't want to, they can write in the talk page about the specific problems they think the page has.

Then there are the in-between cases, like a wiki about movies, where anyone who visits the wiki can give a rating to any movie, and the wiki averages out everyone's ratings. There are various technical issues that make this difficult to implement in SMW and SF, but equally importantly, I just don't see this in the same "universe" of information as data like the movie's director, actors, etc. Querying it alongside real data seems odd to me. I know other people have different opinions on this.

I should note that for cases like that, if you really want to query the data, a good long-term solution might be to try to use the External Data extension to get the ratings data stored by the specialized ratings extension, then store it semantically and query it; instead of trying to use SF in some roundabout way. But I don't know if that's feasible right now.

Which brings us back to the original example, about boats. Thinking about it more now, what I might actually suggest is to take the approach ardorado.com takes - store the information on user pages, instead of on the boat pages. Of course, it's a little trickier to put in an "add to my favorites" link on a boat page, that edits the user page; but it's doable - maybe Sergey can even send you the custom code they created for their site. :) I believe it involved the POM extension.

-Yaron

[najevi]

Thanks for the feedback so far. I will study the ardorado.com site to
see if that inspires a different approach.

- - - The fix - - -
The fix for my specific application was to change:

{{{field|Operation|radiobutton|default=Remove|mandatory}}}

to:
{{{field|Operation|property=Operation|input type=radiobutton|
default=Remove|mandatory}}}

"|property=Operation" came from Yaron
"|input type=" came from a good night's sleep!

You can now see this behaving (almost) as intended at
http://smwtest.wikia.com/wiki/Special:EditData/Favorites/Skin27

I say "almost" because my intended preload of the edit summary text is
still not working as advertised and I loath page edits that don't
include a summary!

- - - What is social networking data and how does it really matter? -
- -

Yaron's comment about rating a wiki article is something I agree with.
Any given article per-se is in a constant state of evolution so
ratings are only meaningful if they are contemporary. Having said that
we should remember that semantic queries are easily able to filter out
older (stale) votes ... so maybe semantic data really _is_ an ideal
tool to achieve that goal after all. mmm!

The notion of favorites as described in the OP has great value to a
community. The primary difference being that a user's "favorite" vote
is data rating the _subject_ of an article and not the article itself.
I can't demonstrate this today so I can only describe an idea:
As a wiki community look at where the best return on investment can be
enjoyed, having this type of data (popularity of a concept) accessible
is especially useful. At the specific wiki I am working on right now I
imagine that data helping the community of virtual skippers to develop
race tracks (or skins or boat models) and host races in a way that is
more popular ... for whatever reason.

- - - Should privacy be a concern? - - -

An important consideration was how much effort should go into hiding
the fact that a UserA likes the subject of an article. I imagine that
there will be the paranoid community member who would prefer not to
have their user name "attached" to an article. In the solution I have
taken this cannot be avoided. If the article list is maintained at the
User:UserA page or sub-page then it is still accessible to the public
who know how.

An IRC user in either #semanticmediawiki or #wikia pointed out that
"there are no secrets at a wiki" and so I decided to settle for
obfuscation to give the (albeit superficial) appearance of privacy
being addressed. (I plan to use __NOFACTBOX__ magic word in the pages
I described earlier.)

[najevi]

== Bug report ==
{{field ... |default=current user ... }}

is not substituting the name of the user who is currently attempting
to edit the page using a form. Instead, it is returning the name of
whichever user initially *created* the current page.

I am certain that is a bug or at best bad description at the
documentation page: http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Form_markup_language
Quote:
"
default=default value - Specifies a default value for this field. For
date-related fields, default=now will set the value to the current
date and possibly time. For text fields, default=current user will set
the value to the username of the user adding this page.
"

If "|default=now" returned the date-time-stamp of whenever the current
page was initially *created* than I am certain that a reasonable
person would consider that to be a bug.
By that same argument I will assume the present behavior for "|
default=current user" to also be a bug. ... until told differently!

Test cases:
http://smwtest.wikia.com/wiki/Special:EditData/Favorites/Skin31 -
created by user: Delica
http://smwtest.wikia.com/wiki/Special:EditData/Favorites/Skin27 -
created by user: Najevi

To assist debug, I have temporarily made the "This user" property
value visible in that partial form.

== Possibly helpful ==
IRC user padde reports that the code for this shows:
[16:34] <padde> // if the field is a text field, and its default
value was set
[16:34] <padde> // to 'current user', and it has no current value, set
$cur_value
[16:34] <padde> // to be the current user
source: includes/SF_FormPrinter.inc

I am a user and not a developer so I don't plan to go investigating
such include files. As a practical matter I can do nothing about them
since I rely on Wikia for such "back end" assistance and they also
seem quite new to SMW/SF.

[Yaron Koren]

Hi,

Well, defaults and preloads only apply when you're adding a new page (or data), not editing an existing one - I don't quite understand how your setup works, but somehow the system needs to differentiate between a user who has already entered their "favorite" information and one who hasn't.

-Yaron

[najevi]

mmm ... Why limit the scope of default and preload to the act of
*creating* a page?

If there is a good reason for limiting the scope then might I suggest
the "current user" keyword be changed to "page creator" to better
reflect the singular, historical nature of the username that will be
substituted. The choice of word "adding" is unfortunate because it is
easily interpreted to mean adding data to a pre-existing page as well
as the act of adding a new page.

However rather than limiting the scope, I encourage you to imagine the
possibilities if "current user" really does substitute a username that
reflects the user who is presently interacting with the semantic form
to edit an existing page. (For an unregistered user perhaps that
'username' is their IP address.)

- - - -

I am not sure what system you are referring to but my system (or setup
as you call it) uses the string property "Is a favorite of"

Of course, each username is a simple string. By repeatedly annotating
username strings with this one property a comma separated list of
usernames becomes associated with any given page.

Ideally a user can add or remove just their own username and not
another's name. (This is why it became important to me that "|
default=current user" be contemporary with whichever user is currently
interacting with the semantic form - regardless of whether they are
using a partial form, the default form or an alternate form.)

So within that setup the act of removing a username from the list of
usernames is a string replace operation. Adding a username is a simple
semantic annotation - even if it is found to be redundant.

I don't attempt to detect whether or not the username is already in
the list. It isn't important to the task at hand.

- - -

As an expedient workaround I have added the [[category:Users]] tag to
each User:Username page. (Wikia provides a welcome message bot that
will continue with that for newcomers.)

I then use an "|input type=dropdown" for the form and "|values from
category=Users" to effectively restrict string input to just the set
of registered usernames. The obvious down side to this workaround is
that it does allow one user to add another user's name to the "Is a
favorite of" delimited list.

On Jul 17, 10:33 pm, Yaron Koren <yaro...@gmail.com> wrote:
> Hi,
>
> Well, defaults and preloads only apply when you're adding a new page (or
> data), not editing an existing one - I don't quite understand how your setup
> works, but somehow the system needs to differentiate between a user who has
> already entered their "favorite" information and one who hasn't.
>
> -Yaron
>
> On Fri, Jul 17, 2009 at 2:56 AM, najevi <naj...@gmail.com> wrote:
>
> > == Bug report ==
> > {{field ... |default=current user ... }}
>
> > is not substituting the name of the user who is currently attempting
> > to edit the page using a form. Instead, it is returning the name of
> > whichever user initially *created* the current page.
>
> > I am certain that is a bug or at best bad description at the
> > documentation page:

> >http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Form_markup_la...

[Bernhard Krabina]

Don't want to interfere your in-depth discussion too much with my
general comments. I see you point now, Yaron. But it is only true if
you think as ratings of pages. I'd rather see them as rating the ting
that is described on the page. On of my wikis is about projects that
were submitted to an award. A rating would not rate the quality of the
page (a good or a bad description of the project), but the project
itself: is it more interesting than other? Is it a best-practice?
Mediocre projects can be described very well and very interesting
projects can be described very poorly...

Even when somebody dislikes a page you are right, it would be better
to improve it, but it could be possible that an admin has protected a
page and regular users can not improve it, but they could rate it (so
admins would have a sense on what pages should be improved with a
higher priority). Other use cases are sites where Semantic MediaWiki
is used as an online database rather than a real wiki. Look at
http://www.epsa-projects.com. It is no wiki, as it is not possible to
edit the content except for admins. So there is no real wiki approach
behind it, but still the used software makes a great page.

> I should note that for cases like that, if you really want to query the
> data, a good long-term solution might be to try to use the External Data
> extension to get the ratings data stored by the specialized ratings
> extension, then store it semantically and query it; instead of trying to use
> SF in some roundabout way. But I don't know if that's feasible right now.

This sounds like something I should try out one day...
- Bernhard