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). (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). (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 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. If you want some semantic data editable on many pages, you better decouple it first from the wiki texts. 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. == 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. 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
pgpoIjTtmALyI.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
