Psst, that's where the "collaboration" part comes in. Surely you've heard of
it...if not, http://en.wikipedia.org/wiki/Collaboration
By working with Gero (only current DPL developer that I'm aware of) in adding
semantic support to DPL, you won't need to "reinvent
the wheel" by adding it into Semantic Forms. DPL is basically a glorified
Semantic MediaWiki (SMW) anyway, allowing lists of
articles that link to other articles, and MANY other variations of list
creation. You (and SMWdevs) really need to familiarize
yourself with it as it essentially replaces most of SMW functionality more
easily without having to add odd link markup ("::" and
":="), dorking with relations/attributes/types/properties (whatever), etc. DPL
takes existing MediaWiki functionality (links,
categories, and namespaces) and simply combines them (set unions, essentially)
that can replace most of what SMW is all about.
I'm finding using DPL to be FAR easier than SMW. Instead of showing complicated
relations/attributes, I simple use DPL to generate a
list of articles in a specific category that link to a specific word (and its
redirects). So, instead of having to go to some
obscure [[relation:weather]] page, I simple go to [[weather]] (which redirects
to [[category:weather]]) and see all articles in the
"games" category that link to "weather". And the same with "wind" (which is an
article in the "weather" category). Simple; basic,
default MediaWiki functionality used intuitively without requiring extra
database tables and increased server load looking up all
those relations/attributes for EVERY page (which, in turn, slows down the wiki,
causing pages to load longer).
To SMW-related devs (that includes you, Yaron, and Gero), I suggest working
together collaboratively to find the best implementation
of dynamic data in MediaWiki--and a GUI to easily manipulate it. DPL is perhaps
the closest, integrating Simple Forms into its query
page, but the connection between creating forms to generate tabular
database-like articles for listing into tables or other various
inclusion options (as DPL can do) hasn't been formed yet in Semantic MediaWiki.
I see the big picture where all of these extensions
can go once they come together and start working together--I hope you devs do
too now...
From: Yaron Koren
Sent: Wednesday, August 22, 2007 2:33 PM
DPL is Dynamic Page Lists, a MediaWiki extension I mentioned in my email.
Eep, as you may or may not realize, Semantic MediaWiki and Semantic Forms are
two separate extensions, with two separate sets of
developers. It's Semantic MediaWiki that does data access, and I have no
control over the development of that one (not that I would
necessarily add metadata support to it if I could, but it's a moot point
anyway.)
On 8/22/07, Michael F Uschold <[EMAIL PROTECTED]> wrote:
I just googled [DPL wiki] and found nothing useful. What is DPL?
On 8/22/07, Eep² <[EMAIL PROTECTED] > wrote:
Er, why not just work with DPL in getting it to access semantic data?
Collaboration...
From: Yaron Koren
Sent: Wednesday, August 22, 2007 11:51 AM
One feature that it would definitely be nice to have is a way to sort/display
pages by the time they were last modified, and perhaps
by the user who last modified them as well. Of all the metadata, these, I
think, are the ones that it would be the nicest to be able
to query when creating lists: definitely the first one, anyway, judging by my
own needs and by what I've seen on the Semantic
MediaWiki mailing list.
The problem is that metadata like this is not stored as semantic information,
and thus can't be included in SMW's inline queries.
Dymanic Page Lists allows for this kind of querying, but it can't access the
semantic data, and the two extensions can't work
together with one another. So, for the moment, there's no way to do it. It
could be that, at some point, SMW will add in support for
querying non-semantic page metadata; I don't know of any such a plan, but you
never know.
One possible approach, though, is to have Semantic Forms store this kind of
data semantically. You could imagine a new input type,
called, say, "timestamp", that would show up in the form as something like
"{{{field|last modified|input type=timestamp}}}". This
would probably be a hidden field, that the user couldn't see or edit, and it
would be set to whatever time the form was submitted.
It would then populate a field within some template, and thus become a semantic
field that was queryable. You could have something
very similar for the person who last edited the page, with an input type
called, say, "last editor".
What do people think of such a solution? It's obviously an imperfect solution,
and somewhat of a hack. Among other problems:
- if a page was edited conventionally, instead of through a form, the field(s)
wouldn't change.
- a user could actually edit this information, again with the conventional edit
tab, to have incorrect values.
- it means that the same data would be stored twice, which violates a few
database principles.
Is it too much of a hack to add in? Any thoughts are appreciated.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
