|
Yaron Koren wrote on 05/09/07 20:40:
Well, I'm not really involved in the core development of
SMW, so it's
not up to me. But I'd say that, though is a very interesting idea, I'd
argue against turning SMW into an extensible solution. I think one of
the big strengths of SMW is that it's a relatively simple concept -
there's only one way to declare a relation or attribute, and there's
only one place (that is, one page) where you can store any specific
relation or attribute. This ties in to the discussion about arbitrary
triples we were having before - I think it's very nice that, when you
see a semantic relationship on any SMW site, you know exactly where to
go if you want to edit it.
the main drive here is that using semantic mediawiki is a great impact
on how you use your wiki, so, like mediawiki, it should be extendable,
to allow for all the uses people will want from it. some extensions of
mediawiki that i use may confuse people used to other wikis (without
those extensions), esp. semantic-mediawiki, so does it mean i should
only work with a vanilla mediawiki installation? if i'm developing a
public wiki, for the whole world to use, then probably yes, but if i'm
developing it for a small community of people, the benefits i get
outweigh this risk of conufsion.
For a similar reason, I'm against allowing arbitary markup schemes -
it would mean people would lose the ability to have consistent editing
across all SMW sites.
as semantic-mediawiki causes them to loose the ability to have
consistent editing across all MW sites (or they won't use it).
the point is to give a standard syntax, and allow those with special
needs to change it. they will take into consideration their break from
consistency.
In general, I prefer simplicity over flexibility, everything else
being equal. I'm thinking of various applications and languages that
have gotten more bloated and harder-to-use as they've been given more
features and more ways to do any one thing.
exactly what i'm driving at. give a simple semantic-mediawiki, for the
wide masses. something like today: simple relations, always contained
in the subject page. but, have a way for more sophisticated users to
break out of this.
My 2 cents,
-Yaron
On 5/9/07, Ittay Dror <[EMAIL PROTECTED]> wrote:
Hi,
With all the discussion about different syntax, capabilities and views,
wouldn't it be nice to make semantic mediawiki extensible? (in the same
way
as protege)
What I would suggest (sorry if this is too brief, if hard to understand
(and
you wish to), i can elaborate):
- an independent library for storing (and maybe querying) semantic data
-
best to find something already implemented (in this case, it probably
need
to have pluggable storages, so semantic mediawiki can use the wiki's
database). this should just provide the API. this is in fact, the basic
core. other extensions use it.
- extension #1 - a parser that extracts all texts that contain semantic
data. extensions to the parser can do the actual parsing of the data
(using
different syntax) and return the triplets which are then saved. the
parser
then hands off the rendering of the text to another extension. this
extension is just a nice-to-have, for someone that does want to have a
different syntax, but doesn't want to learn the ugliness of mediawiki.
- extension #2 - the default relation syntax parser. best if this can
be
extendable also. this can be done by parsing the relation, creating an
_expression_ tree, possibly with unknown tokens, and then letting
extensions
take over. e.g., using xml.
- extension #3 - queries. a base extension that receives the query,
passes
it onto another extension to handle it and, either returns the triplets
matching the query, or, return some uniform query language to return a
standard query which the extension then executes to get triplets. the
extension then proceeds to render the results, again using extensions
(e.g.,
provide a graph rendering of the relations).
- basic rendering extensions - table, list, timeline.
- data type extensions - these are available already, but just make it
standard interface with the extensions above.
- hooks for different events - relation creation, update, delete.
before
store, after store, before retrieve, after retrieve, etc.
- incorporate the extension to design forms that fill in the semantic
data
(posted not long ago)- i really like this as usually relations mean
structured data, which is more easily handled by a form.
- factbox extension - just to hide the ugliness of mediawiki and allow
other
extensions to actually render the factbox (maybe stack them)
- allow extensions to directly create triplets. this may mean that the
'origin' of the triplet may not be a page. this allows inference
engines,
scripting, import relations, etc.
please tell me what you think,
ittay
--
Ittay Dror
Chief Architect,
R&D, Qlusters Inc.
Web: qlusters.com
Email: [EMAIL PROTECTED]
Phone: +972-3-6081994
openQRM - Data Center Provisioning
-------------------------------------------------------------------------
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
|
