Wherever you want to store the sortkey is fine with me. I would think it would actually be easier to store it in the "instances" table, since they're already defined per category (if a page has two different sortkeys for two different categories, which one would you go with?) But on a practical level, either way would be alright - there aren't many cases where a page really would have more than one sortkey value.


On Fri, Jun 20, 2008 at 6:17 AM, Jon Lang <dataweaver@gmail.com> wrote:
Markus Krötzsch wrote:
> I agree that a sortkey would be a useful option, but I would not restrict it
> to the page's role as the instance of some class. Rather one could have a
> universal sortkey used for all queries where pages are sorted by their own
> name. So one would use some special property [[sortkey:: ...]] or the like
> and store that key globally for some page (stored together with the smwids).
> All SMW sorting by title would then just use this data field. Of course, one
> can then not have different sortkeys for each category or property that some
> page uses, but that would be difficult to achieve anyway (and possibly
> confusing or too complex).

As much as possible, SMW should remain a superset of MW; so since MW
provides category-specific sortkeys, so should SMW.  That said, I like
the idea of a special sortkey property designed for use with SMW
queries as you describe above; just don't remove the existing
category-specific sortkeys when doing so.

Jonathan "Dataweaver" Lang