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

Reply via email to