Hi,
Correct me if I'm wrong, but: your argument against using categories only as
indicators of "class" (which is still my preferred approach) seems to be
two-fold: first, that their ease-of-use makes them preferable to using
semantic properties - in other words, it's a waste of the nice functionality
of categories to only use them for limited purposes; and second, that
categories and classes are two different things that don't really make sense
being conjoined anyway. Is that right?
If so, I would actually disagree with both of those: for the first, it's
true that categories automatically create a nicely-formatted page listing
all of their members; but it's not that hard to create a page that could
create a similar list using an inline query or, yes, an inline query
template; and inline queries are in some ways better, in that they allow you
to display additional information on each page. Maybe what would help would
be a format for inline queries that mimics the nicely-alphabetized structure
of category pages?
For the second, I would argue that categories are in fact a good match for
classes. They both generally allow only one kind of relationship to them
("is-a"), and they both have automatic inheritance, meaning that if you
belong to a class or category, you're automatically a member of any of its
parent classes or categories.
-Yaron
On Tue, Mar 4, 2008 at 12:35 AM, Jon Lang <[EMAIL PROTECTED]> wrote:
> 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 concept-set of ontologies, even if we
> wanted to; so the issue is what to do with the concept-set of the
> wiki. As I see it, the possibilities are:
>
> * replace the 'category' notion with the 'class' notion. This is what
> Yaron and S Page are proposing. Downside: you have to reintroduce the
> 'category' notion in some other way, or do without.
> * Introduce a 'class' notion into SMW that's distinct from the
> 'category' notion. This would involve a separate namespace for
> classes.
> * Introduce the 'class' notion into SMW as a subset of the 'category'
> notion. This would involve discriminating between those "categories"
> that might theoretically impose restrictions on their members vs.
> those that won't.
> * Introduce the 'class' notion into SMW as a variant of the 'category'
> notion. This is the approach that I have illustrated earlier in this
> message.
>
> > 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.
>
> Would it be possible to write an extension that does this, or would I
> have to hack SMW_SpecialExportRDF.php?
>
> Also, I'm not just concerned about how RDF exports work; I merely see
> that as a reflection of an internal problem. When and if SMW
> implements more semantic features (such as allowing classes to place
> restrictions on what their members should and should not be like), the
> distinction between "ontological class" and "wiki category" will rise
> up to bite us. As such, I'm looking for a way to distinguish between
> "article A is a member of ontological class C, and thus is subject to
> whatever semantic requirements class C sees fit to impose on it" and
> "article A is included in wiki category C, and thus has no reason to
> expect category C to impose any semantic restrictions on it".
>
> > > 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.
>
> True enough. The only reason why I mention this is that if a category
> isn't associated with an article or subcategory in an RDF export by
> means of rdf:type and rdfs:subClassOf, then how _is_ the association
> handled? This would be the technical argument for equating
> '[[Category:foo]]' with an is-a relation by default: it takes less
> work on the designer's part to implement it that way. Of course, ease
> of programming, while important, isn't necessarily the top priority.
>
> > 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.)
>
> That would be one way to do it; but you'd want to associate the two
> categories so that people could switch between the two kinds of
> articles. Another would be to use [[Topic::Category:foo]] annotations
> in articles, and then include an inline query on the category page
> that lists all pages with that annotation. This seems rather kludgey
> to me; but it does the job.
>
> I've already stated my preferred approach, which is at the very least
> competitive with these approaches.
>
> Unless I'm missing something?
>
> --
> 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
