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@...> wrote:
> Markus Krötzsch wrote:
> > I agree that a sortkey would be a useful option, but I would not restrict
> > 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
> > name. So one would use some special property [[sortkey:: ...]] or the
> > and store that key globally for some page (stored together with the
> > All SMW sorting by title would then just use this data field. Of course,
> > can then not have different sortkeys for each category or property that
> > 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