Thanks for this
M&CT, Phantom Works
COOL TIP: to skip the phone menu tree and get a human on the phone, go to: http://gethuman.com/tips.html
From: Markus Krötzsch [mailto:firstname.lastname@example.org]
Sent: Saturday, April 28, 2007 7:18 AM
Subject: Re: [swikig] [Semediawiki-user] Creating Triples Anywhere in aSemantic Wiki
Not replying to any contribution to this interesting discussion in particular, here are some of my views (which are currently very close to "Semantic MediaWiki's views" ;-).
== Separating pages and triples/axioms ==
(1) "Relevant semantic content should be (read) accessible in many contexts, not just where it was created."
: I agree. SMW now has a simple data browser that shows all data relating to some page, not just the data entered on that page. And there are many other ways to read semantic data in many contexts.
(2) "Some semantic data should be decoupled from concrete pages."
: Yes, probably. Take the disjointness of two classes as expressed in OWL.
Even if you have pages for both classes, you cannot cleave the axiom to either of them. Note how this is different from cases like subclass (or
subcategory) axioms, where you can just decide to make one of the involved classes the distinguished page to put such an axiom on. Users quickly learn this (at least I never heard a proposal to decouple subcategory statements from pages in MediaWiki).
MU: What if I'm on a class, I might want to specify a new superclass. Are you saying I have to go to the superclass and specify the subclass there? How can the developer know in advance how a user is thinking? Sure, you can force users to do things in a certain way that you 'just decide' but now you make their life difficult.
I'm a decent guy and like to do my share, so I'm willing to put in some suffering for a good cause.
What is that good cause? Who benefits from from this design decision?
For example, if I'm the only one of millions
of users who even cares about this issue, then clearly there is a benefit both
to developers who have less work to do, and to [all other] users who benefit
from developers spending their time on more important
(3) "All semantic data should be decoupled from any concrete pages wiki text."
: No idea. There are many known pros and cons for this. SMW has made its design decision a long time ago, but maybe some future version will offer full decoupling as an option (given that an extension of (2) is implemented one can always disable all annotation syntax).
MU: Ok, the coupling is a result of a prior design decision, perhaps it is just too deeply embedded to change.
(4) "In the text of a single page, it should be possible to describe annotations about any other page."
: At least for MediaWiki, this is technical suicide. If annotations in many pages' source texts...
MU: I assume you mean "semantic annotation" i.e. triple. If not, then ignore this.
Here is where we are not on the same page. Current implementation decisions may require it, but I don't require the semantic annotations to be IN A SOURCE PAGE. Perhaps they could be in a back end, and visible when needed.
...would affect the same issue, one would have to change all of those pages' contents when a user edits one. This requires you to find out where in the source code a statement was made and how it can be changed. In MediaWiki, you can have multi-level transclusion of pages (templates etc.) combined with conditionals, automated string manipulations, and usage of data from external sources, all of which are not constrained by a well-defined syntax but are mere concatenations of operational preprocessing steps on plain text. In general, it is not possible to automatically manipulate this syntax to a predictable effect.
MU: this is now out of my technical depth. The punch line seems to be that with the current code infrastructure, it is not possible or practical. If so, maybe I'm just out of luck.
If you want some semantic data editable on many pages, you better decouple it first from the wiki texts.
MU: perhaps this what I'm advocating, and maybe it is impractical.
Of course this also says: please be careful when designing the next wiki engine that might become a market leader ...
(5) "When viewing an annotation somewhere in the wiki, one should directly be able to edit it."
: This faces the same problems as (4), so it would need complete decoupling of semantics and wiki text, or a very cleanly designed wiki engine. Anyway, one should keep in mind that most users of many wikis are readers. Offering edit buttons/widgets for every single fact may be more irritating to them than it is helpful to the wiki authors.
MU: yes ther are tradeoffs, and different users will have different preferences.
== Capturing auxiliary triples ==
(6) "The wiki should support the annotation of many different items (e.g. from the Long List) that are given in one page."
: Probably yes, though some details must be discussed there. This use case suggests to specify many subjects on one page, but those subjects might well be local to the page. This does not require strong decoupling of annotations and pages, since triples still can be accessed only from one page where they appear as "sub-subjects".
(7) "The wiki should provide special support for common modelling tasks, where one otherwise would have to create 'auxiliary' pages."
: Yes, at least in certain cases. For instance, we have already discussed earlier on semediawiki-devel the possible support for n-ary relations in SMW.
In OWL and RDF, modelling n-ary relations requires the use of auxiliary facts that are often not suitable for explicit representation in a wiki. But instead of allowing users to manually create auxiliary resources on one page manually, the system probably should rather just accept some n-ary annotation and internally create a suitable structure.
SMW is approaching some of those issues for future releases, but implementation in a real system typically is much more work than designing a nice principle solution.
MU: yes indeed, I'm just a user and I just want you to wave a wand and have it in the next release. :-))
Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe
email@example.com phone +49 (0)721 608 7362
www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717