Eep, I don't think you realize the differences between DPL and SMW - DPL is not glorified SMW, it's simplified query extension comparing to SMW and their approaches are fundamentally different.

It's quite hard to explain to non-technical person, but SMW has "Semantic" in it because it's based on the ideas of Semantic Web, triples, RDF model (not to be confused with RDF/XML serialization which it also supports) and so on.

These differences make collaboration between these two projects quite problematic. And I understand why it's hard to get for a non-technical person. In any case, it's for developers of SMW and DPL to decide on such things.

And not to give you the wrong idea of SMW community denying DPL features, I can assure you that they are desired in SMW, but due to the nature of the approach it should be done differently - ideally, all information of MediaWiki "Title" object should be available for querying the same way it's parsed content is available, this way it will be possible to use this data in any combinations with other data in the system.

I'll be happy to hear from developers of all the extensions and hope that this demand for the functionality from end-user will not get missed in the pile of other features.

           Sergey


On 8/23/07, Eepē <eep@tnlc.com> wrote:

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 <uschold@gmail.com> wrote:
I just googled [DPL wiki] and found nothing useful. What is DPL?


On 8/22/07, Eepē < eep@tnlc.com > 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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Semantic Forms" group.
To post to this group, send email to semantic-forms@googlegroups.com
To unsubscribe from this group, send email to semantic-forms-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---