What's up, Dataweaver,
The topic *has* been discussed before, but it's still an interesting one,
and apparently it hasn't been discussed enough because there still doesn't
seem to be consensus on the issue. :) That quote in the documentation is
interesting - I hadn't seen it before. I personally think it should be
updated to indicate that this is a description of the way things *currently
are*, not at all a recommendation - I believe that categories should only
ever be used to indicate class. Otherwise, as you note, the current system
would need a variety of changes to be able to differentiate the one kind of
category from the other.
And if Wikipedia ever does adopt SMW, I would look forward to a mass
deletion of categories over the span of, say, several weeks. :)
-Yaron
On Sun, Mar 2, 2008 at 5:58 PM, Jon Lang <[EMAIL PROTECTED]> wrote:
> I'm a newcomer here, so it's possible that this has been discussed to
> death and I simply haven't found the relevant topics (although I
> _have_ looked). Bearing that in mind:
>
> I ran across the following statement on the SMW Help pages (in
> particular, <
> http://semantic-mediawiki.org/wiki/Help:RDF_export#Categories
> >):
>
> "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."
>
> This strikes me as being a potentially serious problem, especially
> when it comes to using an external ontology manager to do further
> analysis on the appropriate SMW articles. Conversely, it was
> indicated elsewhere that these conflicting usages are actually quite
> desirable as far as wikis are concerned, since categories are supposed
> to group together articles of common interest.
>
> >From the above, it seems to me that Categories are _not_ the
> appropriate equivalent to OWL/RDF classes. That is, the presence of a
> '[[Category:xxx]]' annotation in an article should not automatically
> map to an rdf:type element; nor should its presence in a Category page
> automatically map to an rdfs:subClassOf element. Bear with me,
> please.
>
> OTOH, I do agree that whatever annotation does map to rdf:type and
> rdfs:subClassOf should be something that causes the article or
> category in question to be added to a category.
>
> Here's what I'm proposing:
>
> 1. Add a new Property Type: namely, Type:Category. Like Type:Page,
> Properties of Type:Category define a relation between two pages.
> Unlike Type:Page, the page being pointed to is always a Category; and
> including this Property on a page implicitly categorizes it.
>
> By annotating pages with properties of this type, it becomes possible
> to distinguish between different reasons for including the page in the
> category.
>
> 2. Add a new special property: 'Class'. Property:Class has type
> Category; additionally, only categorization by means of Property:Class
> would map to rdf:type and rdfs:subClassOf; all other means of
> categorization (including the traditional '[[Category:foo]]'
> annotation) would map to owl:ObjectProperty.
>
> I'd also add a special property 'Category'. Categorizing through it
> would be identical to categorizing by the traditional mechanism: that
> is, '[[Category::foo]]' would be completely interchangeable with
> '[[Category:foo]]'. But this isn't strictly necessary; it's merely
> one way that you might ensure that you have a way of mapping
> '[[Category:foo]]' to an owl:ObjectProperty element.
>
> --
>
> The main downside that I see to this proposal is that semantic wikis
> that adopt it would have to be thoroughly reviewed in terms of their
> category annotations. OTOH, the only alternatives that I see would be
> for a semantic wiki to insist that Categories only be used to
> represent 'is-a' relationships, or for the semantic wiki to ignore the
> issue. (Technically, you could reverse my proposal by providing a
> special Property that categorizes the page without establishing a
> class/instance-or-subclass relationship when exported; but this is
> essentially the same solution, changing only the "burden of proof", as
> it were.) It's possible for either of these to be viable solutions: a
> wiki that's built entirely around a given vocabulary can get away with
> mandating that all articles in a category must be instances of its
> class, and an open-ended wiki such as Wikipedia may not encounter this
> issue often enough to warrant the amount of work that would be needed
> to fix the problem.
>
> With this in mind, it's entirely possible that I'm proposing an SMW
> Extension, rather than an upgrade. That way, those wikis that want to
> implement this could, while those that don't want to bother with it
> don't have to.
>
> Thoughts?
>
> --
> Jonathan "Dataweaver" Lang
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
