Re: [SMW-devel] Classes vs. Categories
See http://biomedgt.org/ or http://www.wiktolog.org/agrowiki/ (the latter is slightly out of date at the moment, but it includes an idea of what might be done with basic OWL/Dublin Core and the like). These examples are slightly different cases, however, as are importing classes *into* the wiki rather than creating them. As we are developing ontologies and classification schemes, there is very little use of instances. It is our hope that ontology developers will be able use these resources (or at least the first one) to comment on and propose changes to the ontology contents. We export these proposals in a Protege-OWL editor through the RDF export mechanism, although we have to do a goodly amount of transformation to accomplish this. Ideally, we would like to reach the point where we can generate real OWL through the RDF when applicable. As an aside, we have to tweak the auto-completion code in SemanticForms to enumerate Categories rather than just articles. As no one else seems to have this requirement, we are assuming that our use case is somewhat non-standard. The Mayo Clinic is also developing a similar mechanism to curate the contents of the International Classification of Diseases version 10 (ICD-10), but this isn't publicly available at this time. Harold Solbrig Apelon, Inc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Thompson Sent: Wednesday, March 05, 2008 12:24 PM To: Semantic MediaWiki devs Subject: Re: [SMW-devel] Classes vs. Categories Jon Lang wrote: Jeff Thompson wrote: Good points about the difference between OWL DL and OWL Full. So if you only want to export OWL DL, what would you do with a page like the President or Dog or Wine pages on Wikipedia, which are pages about a class. Place articles about classes in the Category namespace. This is indeed the logical answer. I asked the question trying to be provocative since I haven't seen a wiki where main articles like Dog are put in the Category namespace. Have you seen this in practice? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/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/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
Thanks for the links. On biomedgt, I see that the Category inheritance is used to make a class heirarchy: http://biomedgt.org/index.php?title=Special:CategoryTreetarget=BGT_TopThing(%40)mode=0 Notice that each category not only is the subject of a subClassOf relation, but also many other relations that describe the class, which is not allowed by OWL DL. See the rich fact box for BGT Antigen Gene: http://biomedgt.org/index.php/Category:BGT_Antigen_Gene(B54432) The category BGT Antigen Gene is in the category of BGT Gene as a subclass of it: http://biomedgt.org/index.php/Category:BGT_Gene(B16785) But notice that BGT Gene is in the category BGT Gene Kind. This is not a subclass relation, but rather the class BGT Gene is an instance of the second-order class BGT Gene Kind. Indeed, the RDF export wrongly uses subClassOf: owl:Class rdf:about=http://BiomedGT.org/index.php/Special:URIResolver/Category:BGT_Gene-28B16785-29; rdfs:subClassOf rdf:resource=http://BiomedGT.org/index.php/Special:URIResolver/Category:BGT_Gene_Kind-28B179-29/ /owl:Class So once again, even in this semantically aware application, category is improperly used for both subClassOf and instance of, and many properties other than subClassOf are applied to a class, so we need OWL Full anyway. This is a case for not relying on the wiki category system, and needing explicit subClassOf properties. Harold Solbrig wrote: See http://biomedgt.org/ or http://www.wiktolog.org/agrowiki/ (the latter is slightly out of date at the moment, but it includes an idea of what might be done with basic OWL/Dublin Core and the like). These examples are slightly different cases, however, as are importing classes *into* the wiki rather than creating them. As we are developing ontologies and classification schemes, there is very little use of instances. It is our hope that ontology developers will be able use these resources (or at least the first one) to comment on and propose changes to the ontology contents. We export these proposals in a Protege-OWL editor through the RDF export mechanism, although we have to do a goodly amount of transformation to accomplish this. Ideally, we would like to reach the point where we can generate real OWL through the RDF when applicable. As an aside, we have to tweak the auto-completion code in SemanticForms to enumerate Categories rather than just articles. As no one else seems to have this requirement, we are assuming that our use case is somewhat non-standard. The Mayo Clinic is also developing a similar mechanism to curate the contents of the International Classification of Diseases version 10 (ICD-10), but this isn't publicly available at this time. Harold Solbrig Apelon, Inc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Thompson Sent: Wednesday, March 05, 2008 12:24 PM To: Semantic MediaWiki devs Subject: Re: [SMW-devel] Classes vs. Categories Jon Lang wrote: Jeff Thompson wrote: Good points about the difference between OWL DL and OWL Full. So if you only want to export OWL DL, what would you do with a page like the President or Dog or Wine pages on Wikipedia, which are pages about a class. Place articles about classes in the Category namespace. This is indeed the logical answer. I asked the question trying to be provocative since I haven't seen a wiki where main articles like Dog are put in the Category namespace. Have you seen this in practice? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/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/vse012070mrt/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/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
Jeff Thompson wrote: Good points about the difference between OWL DL and OWL Full. So if you only want to export OWL DL, what would you do with a page like the President or Dog or Wine pages on Wikipedia, which are pages about a class. Place articles about classes in the Category namespace. Again, this is only for the purpose of conforming with OWL DL. With this in mind: the difference between OWL DL and OWL Full is whether or not you respect the usage restrictions placed on you by the former; the syntax of the two sublanguages is the same. I'd be fine with saying that if you want to conform to OWL DL, use the special Class property to establish all is-a relations (and be sure to place articles about classes in the Category namespace; otherwise, the Class property won't be able to target them). If you don't care about OWL DL conformance, use a pair of special properties (say, Subclass of and Member of) that explicitly provide rdfs:subClassOf and rdf:type functionality, respectively (and which point to the main namespace by default). Finally, allow wiki administrators to customize the site based on whether or not they care about OWL DL conformance by disabling the latter two special properties. Better yet, reverse this and require them to explicitly enable violations of OWL DL if they don't care about OWL DL compatibility. -- 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/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
Jon Lang wrote: Jeff Thompson wrote: Good points about the difference between OWL DL and OWL Full. So if you only want to export OWL DL, what would you do with a page like the President or Dog or Wine pages on Wikipedia, which are pages about a class. Place articles about classes in the Category namespace. This is indeed the logical answer. I asked the question trying to be provocative since I haven't seen a wiki where main articles like Dog are put in the Category namespace. Have you seen this in practice? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
Jon Lang wrote: Conversely, the relationship between an article on Urban Planning and a City category is _not_ an is-a relationship: Urban Planning is not a city. But while it's not a valid class/instance relationship, it _is_ a valid category/article relationship. You've voiced distaste for this sort of relationship, and have suggested alternatives that conform to your preference of only using is-a relationships; but that doesn't change the fact that it's still a valid relationship. Very good points. For many reasons, I don't think it is defensible to use page/category in the same way as instance/class. This is an old debate that flares up and goes away without resolution. A very big problem is that many pages are already pages for a class. Consider the Wikipedia page for Dog: http://en.wikipedia.org/wiki/Dog The Dog page is in the category for Dogs. Why do we have a page for Dog and a category for Dogs? Because we need a page to talk about what the Dog class is, and we need a category so that other pages about particular dogs can belong to it. But the relation between the page Dog and the category Dogs is not instance/class. Instead, SMW should support a new relation for this. The Dog page is also in the category Cosmopolitan Species, which is actually correct for an instance/class relation. But notice that Dog is already a class, so Cosmopolitan Species is a class of classes - a second order class. Another example of a class of classes is Heads of State. For example, President and Emporor are instances of the class Heads of State. But President itself is *already a class, which can have instances like George Washington. So there is not a clean boundary where a page is always an individual instance and a category is always (first order) class. This really confuses most people and I think the SMW developers gave up on the idea that people could keep it straight, so it has been left in its vague messy state. I'm not happy with it, but to fix it requires a will to force the SMW user to understand second order classes. - Jeff - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
Jeff Thompson wrote: Another example of a class of classes is Heads of State. For example, President and Emperor are instances of the class Heads of State. But President itself is *already a class, which can have instances like George Washington. Sorry, I screwed up this example. (I'm even getting confused.) Head of State is *not* a second-order class containing President. It is the superclass of President. Here's the test: George Washington is a President, and George Washington is a Head of State. However, Official Title is a second order class containing instances like President and Emperor. Here's the test: President is an Official Title, but George Washington is *not* an Official Title. So SMW should support separate properties for is a and subclass of (apart from Category) because we have to handle: * a page like George Washington is a President, but the President category does not explain what a president is. That is on the President *page*, so you want to like there with is a. * The President page can link to the Heads of State page through a subclass of relation. * The President page can also link to the Titles page through an is a relation. * Hence, a page can be an individual, a first-order class or a second-order class (like Title), etc. and the category system is not able to deal with this. * The only good argument for using Category for classes is that SMW already supports transitive lookup from a category to a super category. But that is laziness. We should be able to support that subclass of is also transitive. - Jeff - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
Yaron Koren wrote: Conversely, the relationship between an article on Urban Planning and a City category is _not_ an is-a relationship: Urban Planning is not a city. But while it's not a valid class/instance relationship, it _is_ a valid category/article relationship. Well, valid is in the eye of the beholder. :) It's valid in Wikipedia, but on other wikis (like mine), it could be considered invalid: technically possible, but incorrect. ...and your solution is to try to change this so that it's invalid for everyone, whether they like it or not. Let's take a look at two possible outcomes: if I get my way, you are still free to insist that people use Categories exclusively for class/instance relations on SMWs that you run, and I am free to permit people to use other kinds of category/article relations on SMWs that I run. If you get your way, you will still be able to handle your semantic wikis the way that you want to; but I will be forced to manage my semantic wikis the way that you think they ought to be managed. The only way that insisting on requiring everyone to use your approach makes any sense is if there are technical difficulties that render the alternative impractical. So far, you have not shown anything of the sort. The best you've managed has been to show that your approach works - which I have never disputed, BTW. _ So: what technical difficulties are there with the alternatives? For clarity, I'll summarize what I consider to be the most appropriate alternative: [*] Add a special property called Class that works exactly like Category annotations currently work. That is: it establishes a class/instance relationship (e.g. rdf:type) between a category and an article, or a class/subclass relationship (e.g. rdfs:subClassOf) between two categories, both conceptually and semantically. [*] Change the implementation of the Category annotation so that it no longer promises anything other than that there is some sort of transitive relationship between the article or category that it's in and the category that it refers to. _ I see one technical difficulty with this, and one other practical difficulty. If you see any others, please let me know. The technical difficulty comes when exporting to OWL/RDF: since you don't represent the generic category/article relationship using rdf:type and you don't represent the generic category/subcategory relationship using rdfs:subClassOf, how _do_ you represent them? Or do you? This difficulty can be resolved by noting that the traditional relationships used for wiki categorization aren't semantic, any more than standard page references are. As far as I can tell, non-Property page references don't get exported to OWL/RDF; so one solution to this dilemma would simply be to not export categorization done by means of '[[Category:xyz]]'. In short, if you want _anything_ on a SMW page to have semantic meaning, use a Property to annotate it. Anything. Including is-a. Conversely, if you don't use a Property to annotate something, it doesn't carry any semantic value. _ The practical difficulty is that there are already SMWs up and running that are using categories as classes. Making this change would require them to replace all existing '[[Category:xyz]]' markup with '[[Class::xyz]]' property annotations in order to maintain exactly the same behavior they currently exhibit. This can be done by bot, but still represents significant effort for little apparent gain. And the longer it takes to implement this change, the more insurmountable this practical difficulty becomes. The only solution that I can see to this dilemma is to implement the change as an extension. The result will be two basic kinds of SMWs: those that use standard Category markup to carry semantics, and those that handle all of their semantics by means of Property annotations. These two varieties can then compete with each other in the general marketplace; if the latter proves popular enough that more new SMWs are using it than aren't, then it can be integrated into the core; if not, at least it's still available to those who want it. -- 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/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
Jeff: you raise some interesting points. Let me try to address them: From what I can tell, SMW is modelling itself after a subset of OWL. This is being done for compatability reasons: if it's modelled after OWL, then it should be trivial to export it as OWL, allowing other applications on the web an easier time in accessing your site without human intervention. OWL comes in three flavors: OWL Lite, OWL DL, and OWL Full. At this point, we can pretty much discount OWL Lite; it isn't doing what it set out to do. This leaves us with OWL DL and OWL Full for consideration. According to the OWL Guide, OWL DL supports those users who want the maximum expressiveness without losing computational completeness (all entailments are guaranteed to be computed) and decidability (all computations will finish in finite time) of reasoning systems. OWL DL includes all OWL language constructs with restrictions such as type separation (a class can not also be an individual or property, a property can not also be an individual or class). Meanwhile, OWL Full is meant for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees. For example, in OWL Full a class can be treated simultaneously as a collection of individuals and as an individual in its own right. It sounds to me that what you're after is akin to the latter: maximum expressiveness and syntactic freedom with no computational guarantees. As such, enforcing a disjunction between class and individual (e.g., restricting classes to the Category namespace and forbidding individuals from being placed in the Category namespace) comes across as an artificial and unnecessary distinction. Meanwhile, I've been approaching this with the idea of ensuring that OWL DL reasoners will be able to make use of the site. This means that SMW has to restrict its semantic capabilities to something that can be mapped to OWL DL. In turn, this means maintaining a strict separation between class and individual. Separating classes and individuals by namespace does this rather elegantly, and using the Category namespace for this purpose has a lot to be said for it - as long as it isn't done to the exclusion of more traditional uses of Categories. In addition, doing this means that you don't need separate properties to represent class membership and subclassing: if the Class property is used outside of the Category namespace, it defines a class/instance relation; if it is used in a Category page, it defines a class/subclass relation. _ That's not to say that there's no merit in your approach, or that it would be difficult to implement. Indeed, all you'd need to do syntactically would be to add '[[Is a::xyz]]' and '[[Subclass of::xyz]]' properties that don't assume that xyz is in the Category namespace. Semantically, you'd need to map these to rdf:type and rdfs:subClassOf, respectively; and you'd need to change the RDF import and export capabilities to be compatible with OWL Full instead of OWL DL. This last bit is potentially the biggest hurdle involved, since it determines which reasoning engines can access the wiki. -- 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/vse012070mrt/direct/01/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
(Mr. Lang/Dreamweaver, welcome to SMW!)
Yaron Koren wrote:
The topic *has* been discussed before,
Indeed, e.g.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00503.html
[The documentation] should be updated to indicate that this is a
description of the way things *currently are*,
not at all a recommendation
I think I wrote
http://semantic-mediawiki.org/wiki/Help:RDF_export#Categories, and I'm
not sure how to improve it. The way SMW's RDF export works is a fact,
and There are many usages of MediaWiki categories that conflict with
these semantics is another fact, it's not a recommendation.
Indeed, this topic arises regularly. However, I believe most SMW wikis
don't do anything with RDF export. (If anyone is doing slick reasoning
with SMW's RDF, speak up and tell us more!) In those wikis, conflicting
usage of MediaWiki categories won't hurt. Somewhere there may be a
Neuromancer, Wintermute, or WOPR blowing a fuse trying to understand
your wiki, but that's not your problem.
*If* accurate RDF representation of your wiki matters, then you have to
decide how to handle categories. There is no best practice here.
Dataweaver's proposal is doable, though a bit complex.
BTW, many have played around with categorization semantics on ontoworld.org:
http://ontoworld.org/wiki/Property:About
http://ontoworld.org/wiki/Help_talk:Category
http://ontoworld.org/wiki/Property:Has_category
http://ontoworld.org/wiki/Category:Topic
http://ontoworld.org/wiki/Property:Classified_by
etc., etc.
After a while the words just turn to mush . Keep it simple!
In my opinion, rather than SMW standardizing on any one elaborate
handling of categorization, it would be better if SMW generalized some
of the useful behavior of MediaWiki categories, such as:
* Displaying anything annotated [[subClassOf::Xyz]] when you view
article Xyz, the same way MediaWiki displays subcategories of Category:Xyz
* Performing transitive queries when you query any property annotated as
owl:TransitiveProperty, the same way SMW queries for articles in
subcategories when you query on Category:Xyz.
Then you could leave categories with their strict interpretation in SMW,
while adding your own classification properties that have useful
behavior. Note that even without PHP code hacking you can make your own
Property:TopicRelatedToSubclassOf have useful behavior by putting inline
query templates on pages.
- 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.
Exactly.
Jonathan Dataweaver Lang originally wrote:
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;
I'm pretty confident a SMW wiki's admin can establish such mappings by
creating articles named MediaWiki:Smw_import_{rdf|rdfs}, see
http://semantic-mediawiki.org/wiki/Help:Import_vocabulary. You might
consider mapping to SKOS, it's more detailed.
ontoworld.org does not have import pages for these ontologies because it
might mislead users to think SMW itself implements their semantics.
To make *only* your Property:Class have this mapping, you'd have to
modify SMW_SpecialExportRDF.php.
I'd also add a special property 'Category'.
Note that there were and probably still are bugs in SMW when you name a
property the same as a namespace, especially with your proposed
Property:Category. Plus it's very confusing.
Yaron later wrote:
if I
were designing that wiki about cities, I'd probably create a category
called Cities, that held every page that was a city, and one called
City information that held pages that were on the topic of cities in
general.
Me too. The English Wikipedia approach is to use the singular
[[Category:City]] for pages on the topic. (BTW I tried to rename
ontoworld's singular category names, but its users have the notion is_a
City and prefer singular category names.)
There's a lot of ways to do it...
Cheers,
--
=S Page
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Classes vs. Categories
S Page wrote: (Mr. Lang/Dreamweaver, welcome to SMW!) Thank you! (And it's Dataweaver.) Yaron Koren wrote: The topic *has* been discussed before, Indeed, e.g. http://www.mail-archive.com/[EMAIL PROTECTED]/msg00503.html [The documentation] should be updated to indicate that this is a description of the way things *currently are*, not at all a recommendation I think I wrote http://semantic-mediawiki.org/wiki/Help:RDF_export#Categories, and I'm not sure how to improve it. The way SMW's RDF export works is a fact, and There are many usages of MediaWiki categories that conflict with these semantics is another fact, it's not a recommendation. That's how I took it: as a pair of conflicting facts, not as a recommendation for how things _should_ be. Indeed, this topic arises regularly. However, I believe most SMW wikis don't do anything with RDF export. (If anyone is doing slick reasoning with SMW's RDF, speak up and tell us more!) In those wikis, conflicting usage of MediaWiki categories won't hurt. In other words, most SMWs can ignore the problem. I suppose that's true; but it still rubs me the wrong way that you _can't_ draw a distinction even if you want to. *If* accurate RDF representation of your wiki matters, then you have to decide how to handle categories. There is no best practice here. Dataweaver's proposal is doable, though a bit complex. It can be streamlined. The core of it is to provide one means of associating a page or category with a category that represents an is-a relationship, and a separate means that doesn't represent an is-a relationship. My own preference would be to use the term class to refer to the former and category to refer to the latter; but I can see the argument for continuing to use category for the former and coming up with some other term (e.g. topic) for the latter. To illustrate: First approach: '[[Class::foo]]' declares the subject of the article to be a member of foo. '[[Category:foo]]' declares that the article discusses a subject involving foo. Second approach: '[[Category:foo]]' declares the subject of the article to be a member of foo. '[[Topic::foo]]' declares that the article discusses a subject involving foo. In my opinion, rather than SMW standardizing on any one elaborate handling of categorization, it would be better if SMW generalized some of the useful behavior of MediaWiki categories, such as: * Displaying anything annotated [[subClassOf::Xyz]] when you view article Xyz, the same way MediaWiki displays subcategories of Category:Xyz Would you also include a [[Type::Xyz]] annotation or something similar to indicate that one page describes an instance of the class described by another page? I can see this getting really messy, really fast. Better to keep the classes and instances in separate namespaces. * Performing transitive queries when you query any property annotated as owl:TransitiveProperty, the same way SMW queries for articles in subcategories when you query on Category:Xyz. That would be useful, yes - as long as I can ignore the transitive characteristic of a property if I only want direct associations. Then you could leave categories with their strict interpretation in SMW, while adding your own classification properties that have useful behavior. Note that even without PHP code hacking you can make your own Property:TopicRelatedToSubclassOf have useful behavior by putting inline query templates on pages. True enough. Of course, the advantage of using Categories for this is that I don't _have_ to put an inline query template on the page: a category page automatically queries for all pages that have it as a category. - 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. Exactly. The problem is that that's not what categories were created to do. They have a common characteristic: ontological classes group instances together, and wiki categories group instances together. But that's the full extent of the similarities. The primary purpose of an ontological class is to present semantic information that applies to all individuals in a set; the primary purpose of a wiki category is to provide easy access to other articles related to the same overall topic. Stated another way, the notion of a wiki category has no parallel concept in ontologies: it is not a class, and it is not an individual - although it's more like a class than it is like an individual. In comparison, the notion of the wiki article parallels very nicely to the notion of the ontological individual. It appears to me that the reason 'class' and 'category' have been equated is that as poor as the fit is, there's nothing else in the respective paradigms that fit better. We can't do anything about the
Re: [SMW-devel] Classes vs. Categories
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.
