Last modified: 2011-03-13 18:05:15 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13213 - New Property Type: Category
New Property Type: Category
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Markus Krötzsch
http://semantic-mediawiki.org/wiki/He...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-01 19:51 UTC by Jonathan Lang
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jonathan Lang 2008-03-01 19:51:49 UTC
In the third paragraph of the cited page, it is stated that "MediaWiki's categories have many different interpretations. For example, the category City might comprise all articles about particular cities, i.e. a member of this category is a city. Or it might describe the topic area of articles, such as articles on city squares, urbanism, etc. Or both. MediaWiki encourages this practical usage of categories: a category forms a collection of articles that are considered useful or interesting for users, and categories are organized so users can browse narrower or broader groupings and find related concepts."

It might be useful to be able to assign types to categories, so that one could specify the reason one is putting a given article in a given category.  A fairly straightforward way to do this (in terms of syntax) would be to add a "Category" type to Semantic MediaWiki, which tells it to treat the Property as if it were a Category.  You could then do things like:

  [[Property:Class]] includes '[[has Type:Category]]'
  [[Property:Topic]] includes '[[has Type:Category]]'
  [[Los Angeles]] includes '[[Class::City]]' instead of '[[Category:City]]'
  [[Urbanism]] includes '[[Topic::City]]' instead of '[[Category:City]]'

Both Los Angeles and Urbanism would be listed under Property:City; but a semantic search for cities would be able to exclude Urbanism and the like by focusing on [[Class::City]].  

A more elaborate implementation of this would also change the way that Category pages are displayed so that articles are grouped according to type: for example, [[:Category:City]] would list all cities (i.e. [[Class::City]]) first, followed by the city-related articles (i.e. [[Topic::City]]), and finally other articles (i.e. [[Category:City]]).  

This is low-priority because you can already achieve most of these results by defining Class and Topic Properties that aren't '[[has Type:Category]]', and then using '[[Class:City]]' or '[[Topic:City]]' on the relevant pages in addition to '[[Category:City]]' rather than instead of it.  The only capability that this skips is the grouping of similar pages in the Category index.
Comment 1 Jonathan Lang 2008-03-02 21:43:27 UTC
Follow-up: the inspiration for this proposal came from http://semantic-mediawiki.org/wiki/Help:RDF_export#Categories where it was mentioned that "There are many usages of MediaWiki categories that conflict with these semantics. For example, the article Urban decay might be in category Cities, but it is not a city. And Category:City museums might be in category Cities, but city museums are not cities."

The semantics in question are that SMW categories are equivalent to OWL/RDF classes.  

This can be a problem if you attempt to have an ontological manager do any reasoning using the assertions made on the wiki.  As such, the original intent of this proposal was to provide a mechanism whereas actual "is a" relationships can be clearly and explicitly defined: [[Property::Class]] should be a special property, with the semantics that only articles that are categorized using this property count as RDF classes; all other means of categorization (including the traditional '[[Category:xxx]]' annotations) should 'merely' result in what used to be known as Relations, as far as importing and exporting are concerned.  

If adopted, this will lead to radical changes in how existing semantic wikis behave, and will require that the participants in the appropriate wikis go through and substitute '[[Class::xxx]]' for '[[Category:xxx]]' everywhere that an actual 'is-a' relationship is intended.  
Comment 2 Siebrand Mazeland 2008-08-11 11:05:26 UTC
Re-assign to extension developer for triage/comments.
Comment 3 Markus Krötzsch 2009-08-02 12:55:15 UTC
I am unsure what to do with this. As is stated above, part of this already works: you could easily have a property "has topic" and this could be given a value "Category:City" or "City" (depending on what you prefer). The new feature that is requested now is that articles with such an annotation would additionally be listed on the Category:City page, even though they do not have [[Category:City]] anywhere in their text. Now again it would be fairly easy to put this extra [[Category:City]] into the article to achieve the same result without any change.

The suggestion for groping entries on the category page appears to be more tricky, and amounts to having a more complex semantic query on each category page. This would also interfere with other extensions that modify/extend the display of category pages, e.g. by inserting category trees. So I doubt that it would work very well. As a workaround, one could achieve similar displays with inline queries on the category page. This would also be more customizable (any automatic display would certainly not be able to fit all use cases).

With these considerations, I am inclined to reject the original feature request. But I agree with the problem of category semantics: it would be better if one could somehow influence whether a category is interpreted as a class (subcategory implying class containment), or as a topic (subcategory meaning subtopic). Since this is somewhat different from what is written above, I have filed this as a separate request: Bug 20039.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links