Semantic MediaWiki

Yaron Koren wrote:
> I'm currently modifying Semantic Drilldown to be able to use the new table
> structure in SMW 1.2, and it looks like the structure is fairly complete -
> the only additional thing it would be nice to see would be a field called
> something like "smw_sortkey" in the "smw_insts2" table, holding the sort key
> that MediaWiki uses when displaying pages in a category. This field could
> even potentially be used by any future "instance of" special properties,
> since you could argue that every page representing a class should be able to
> list its own members in a logical order.

While I'm in favor of the concept, there would be some syntax issues
with such a thing: since a page's sortkey with respect to a given
category takes the place of the usual "alternate text" portion of the
traditional link syntax, it's less suitable to properties, which use
that alternate text section for display purposes (as opposed to
category links, which aren't directly displayed).

OTOH, if we were to introduce a Category type (as a subset of the Page
type), I could see properties with that type behaving just like
category links, up to and including the use of the alternate text
section as a sortkey.  .

-- 
Jonathan "Dataweaver" Lang

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

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.

-Yaron


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
> 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
>