Thanks for this input.
==========================
Michael Uschold
M&CT, Phantom Works
425 373-2845
[EMAIL PROTECTED]
==========================
----------------------------------------------------
COOL TIP: to skip the phone menu tree and get a human on the phone, go to:
http://gethuman.com/tips.html
-----Original Message-----
From: Markus Krötzsch [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 28, 2007 7:18 AM
To: semediawiki-user@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: Re: [swikig] [Semediawiki-user] Creating Triples Anywhere in aSemantic
Wiki
Hi all!
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 things.
--
(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. :-))
Cheers,
Markus
--
Markus Krötzsch
Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe
[EMAIL PROTECTED] phone +49 (0)721 608 7362
www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
