Semantic MediaWiki

Just a short reply: It would be good to have some such formalism, but 
designing a good language is not easy and would introduce another 
programming-like formalism into MW. I think one should seriously 
consider the upcoming LUA support to solve this problem [1]. It would be 
much preferable to have a single scripting language being used for all 
MW in-page programming tasks.

Markus

[1] http://www.mediawiki.org/wiki/Lua_scripting

On 13/02/12 12:03, Stephan Gambke wrote:
> Hi,
>
> for some time now I have thought on how it would be possible to get
> away from introducing yet another new parameter every time a new type
> of dynamic behavior is built into Semantic Forms. With the upcoming
> GSoC 2012 I would like to discuss what I have come up with and if it
> finds enough support would propose it as a project for GSoC.
>
> Currently dynamic behavior of Semantic Forms is achieved by adding
> additional parameters to inputs (or by having dedicated inputs). This
> is a good approach where the dynamic behavior only concerns one input.
> Autocompletion would be an example. It becomes awkward when more than
> one field is concerned, e.g. with show on select. And it fails
> altogether, if more than two inputs are involved or if the desired
> behavior is more complex. Generally any behavior involving two or more
> inputs should not be handled by one of the affected inputs, but by a
> dedicated controlling entity that exists once for every form. In fact,
> in many cases this would even be beneficial where only one input is
> involved, as it would enable one behavior for multiple input types
> without having to duplicate code.
>
> Semantic Forms Rules would be an extension to MediaWiki building on
> the Semantic MediaWiki and Semantic Forms extensions. It would allow a
> much more dynamic behavior of Semantic Forms than currently possible.
>
> The idea is to define rules consisting of triggers, conditions and
> actions. The conditions are evaluated when certain triggers are
> detected. Depending on the result the associated actions would be
> performed. Individual rules could be kept very simple, but the result
> of the evaluation of a rule would be stored and could later be
> referenced in other rules. This way rules could be chained and more
> complex rules could be constructed from simple ones.
>
> You can find the whole idea on
> http://wiki.foxtrott.de/ideas/index.php?title=Semantic_Forms_Rules
>
> What do you think? Would this be useful enough to have someone spend
> three month of work on it? If so, should it be done as proposed? What
> should be changed?
>
> Cheers,
> Stephan
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>

Hi Stephan,

Well, I have no real objection to such an extension getting created -
whether or not anyone used it, it wouldn't affect the rest of the
software. However, it doesn't seem important enough, in my opinion, to
get a slot in the Google Summer of Code - especially since, whether we
go through the Wikimedia Foundation or get accepted ourselves, I'm
guessing that we won't get that many projects - maybe three if we're
lucky. On a practical level, I just don't think there will be that
many cases where complex rules will be helpful; this is based on my
own experience using forms, as well as the questions and requests I
hear from users. It's true that rule-based functionality is still
getting added to Semantic Forms - the latest was "values dependent
on", which was just added in the last version. But "values dependent
on", i.e. having one input's allowed values be dynamically set based
on another's value, was something that quite a few people had asked
about - and it was actually something that I had wanted myself, for
use on discoursedb.org, since pretty much the beginning. The same goes
for "show on select". But beyond that, I just haven't heard, I don't
think, of that many additional needs for rules. The example you have
of a form field that holds the title not being editable, if the page
already exists, is interesting - and actually, I think I recall people
having asked about such a thing (though I'm personally not sure if
it's a good idea - what if someone renames the page and wants to
change that field?). But in general, I'm not aware of a widespread
demand for behavior in forms that SF can't address, that would call
for a general rule-based framework like this one.

By the way, Markus's suggestion of using Lua instead for the syntax is
interesting - I don't know how much simplicity that would add, since
of course SF doesn't use Lua either. (It might make sense for SF to
start using Lua, especially for things like handling the looped
template fields that might replace multiple-instance templates, but I
can't imagine how that would be done at the moment.)

One other possibility would be to use the structure provided by the
Page Schemas extensions instead:

https://www.mediawiki.org/wiki/Extension:Page_Schemas

At the moment it's still not getting widely used, I don't think, but
my hope is that it will, especially as new users come in and see the
benefit of creating all forms through it. It lets you define
additional data for fields, templates or the whole form, so it could
definitely house any rule-based information you wanted. And via the
"EditSchema" page, it can provide helpful, translateable, inline help
for filling in the data, so it might make things easier for admins
trying to create rules.

-Yaron

On Mon, Feb 13, 2012 at 7:42 AM, Markus Krötzsch
<markus@...> wrote:
> Just a short reply: It would be good to have some such formalism, but
> designing a good language is not easy and would introduce another
> programming-like formalism into MW. I think one should seriously
> consider the upcoming LUA support to solve this problem [1]. It would be
> much preferable to have a single scripting language being used for all
> MW in-page programming tasks.
>
> Markus
>
> [1] http://www.mediawiki.org/wiki/Lua_scripting
>
> On 13/02/12 12:03, Stephan Gambke wrote:
>> Hi,
>>
>> for some time now I have thought on how it would be possible to get
>> away from introducing yet another new parameter every time a new type
>> of dynamic behavior is built into Semantic Forms. With the upcoming
>> GSoC 2012 I would like to discuss what I have come up with and if it
>> finds enough support would propose it as a project for GSoC.
>>
>> Currently dynamic behavior of Semantic Forms is achieved by adding
>> additional parameters to inputs (or by having dedicated inputs). This
>> is a good approach where the dynamic behavior only concerns one input.
>> Autocompletion would be an example. It becomes awkward when more than
>> one field is concerned, e.g. with show on select. And it fails
>> altogether, if more than two inputs are involved or if the desired
>> behavior is more complex. Generally any behavior involving two or more
>> inputs should not be handled by one of the affected inputs, but by a
>> dedicated controlling entity that exists once for every form. In fact,
>> in many cases this would even be beneficial where only one input is
>> involved, as it would enable one behavior for multiple input types
>> without having to duplicate code.
>>
>> Semantic Forms Rules would be an extension to MediaWiki building on
>> the Semantic MediaWiki and Semantic Forms extensions. It would allow a
>> much more dynamic behavior of Semantic Forms than currently possible.
>>
>> The idea is to define rules consisting of triggers, conditions and
>> actions. The conditions are evaluated when certain triggers are
>> detected. Depending on the result the associated actions would be
>> performed. Individual rules could be kept very simple, but the result
>> of the evaluation of a rule would be stored and could later be
>> referenced in other rules. This way rules could be chained and more
>> complex rules could be constructed from simple ones.
>>
>> You can find the whole idea on
>> http://wiki.foxtrott.de/ideas/index.php?title=Semantic_Forms_Rules
>>
>> What do you think? Would this be useful enough to have someone spend
>> three month of work on it? If so, should it be done as proposed? What
>> should be changed?
>>
>> Cheers,
>> Stephan
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@...
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Semediawiki-user mailing list
> Semediawiki-user@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user



-- 
WikiWorks · MediaWiki Consulting · http://wikiworks.com

Hey,

> it doesn't seem important enough, in my opinion, to get a slot in the
Google Summer of Code

I tend to agree here. There are things in greater demand that would be
useful to more people that could be done. However, I think this idea should
go on the GSoC page regardless. If we get a very capable student for it,
and have less success for other ideas, then it might very well be worth the
effort.

> But in general, I'm not aware of a widespread demand for behavior in
forms that SF can't address, that would call for a general rule-based
framework like this one.

I'd say that SF can definitely handle the vast majority of use cases
already. Most forms are relatively simple, with complex ones being the
exception. I think there would be more complex forms if there where more
advanced features though, so would not be so quick with saying that there
is no demand at all. People are familiar with basic form features from
other applications, and will demand these if they don't find them. This
does not hold true as much for advanced features, which also typically are
needed by more advanced users, who might be more prone to assuming it
simply can't be done, would take to much work to implement or simply don't
have the time to care about it either way. So I think this feature would
find use when published and documented properly. Nevertheless, it seems
like the 80% of effort to solve the 20% of remaining (potential) use cases.

Having more generic systems is always nice though, so I think SF could
benefit from this extension. At least, if this new more generic system was
actually used by SF. So I think it's worth looking into either putting this
into SF, or moving the existing, more limited, functionality out of it and
into this new extension.

> LUA

+1. Introducing even more special syntax is something I would avoid. Then
again, it will be a while before the LUA stuff is done, and will take
longer before you can use it in SF (or an extension to it).

> One other possibility would be to use the structure provided by the Page
Schemas extensions instead

Yeah, this seems like a nice pragmatic thing to do for now. The parsing
done by the new functionality can be made modular in such a way the XML
parser for PS can be replaced by a LUA one if that ends up being desired at
some point.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--

On 13/02/12 15:57, Jeroen De Dauw wrote:
> Hey,
>
>  > it doesn't seem important enough, in my opinion, to get a slot in the
> Google Summer of Code
>
> I tend to agree here. There are things in greater demand that would be
> useful to more people that could be done. However, I think this idea
> should go on the GSoC page regardless. If we get a very capable student
> for it, and have less success for other ideas, then it might very well
> be worth the effort.
>

+1
The purpose of GSoC is not only to benefit the host project but also to 
allow fresh developers to pursue some interesting (for them) projects, 
i.e., to learn something. So from this perspective, I would not stop a 
good applicant who really wants to do this (or any other sound idea that 
they really want to do). I am sure that the initial discussion with the 
mentor can always lead to a project plan that maintains a good balance 
between being useful and being interesting.

Markus

>>  > it doesn't seem important enough, in my opinion, to get a slot in the
>> Google Summer of Code
>>
>> I tend to agree here. There are things in greater demand that would be
>> useful to more people that could be done. However, I think this idea
>> should go on the GSoC page regardless. If we get a very capable student
>> for it, and have less success for other ideas, then it might very well
>> be worth the effort.
>>
> 
> +1
> The purpose of GSoC is not only to benefit the host project but also to
> allow fresh developers to pursue some interesting (for them) projects,
> i.e., to learn something. So from this perspective, I would not stop a
> good applicant who really wants to do this (or any other sound idea that
> they really want to do). I am sure that the initial discussion with the
> mentor can always lead to a project plan that maintains a good balance
> between being useful and being interesting.

Hi,

thanks for your comments. What I will do is, I will add the task to the
page with the understanding that other project ideas will have
precedence if there are applicants for them.

I guess I will also have a closer look on Page Extensions. I'd rather
not use Lua for this because 1. this would indeed mean introducing
another language for specifying things in forms, 2. MW itself does not
support Lua yet and 3. I simply do not have any experience with it. Of
course, the whole thing would need to be discussed with the student and
the result could well be to go for Lua anyway.

Cheers,
Stephan

Hi,

That sounds like a good idea, and that's what I should have said before -
sorry about that. After all, ultimately it's up to the students, not me or
anyone else, what projects get done.

-Yaron

On Tue, Feb 21, 2012 at 3:13 PM, Stephan Gambke <s7eph4n@...> wrote:

>
>
> >>  > it doesn't seem important enough, in my opinion, to get a slot in the
> >> Google Summer of Code
> >>
> >> I tend to agree here. There are things in greater demand that would be
> >> useful to more people that could be done. However, I think this idea
> >> should go on the GSoC page regardless. If we get a very capable student
> >> for it, and have less success for other ideas, then it might very well
> >> be worth the effort.
> >>
> >
> > +1
> > The purpose of GSoC is not only to benefit the host project but also to
> > allow fresh developers to pursue some interesting (for them) projects,
> > i.e., to learn something. So from this perspective, I would not stop a
> > good applicant who really wants to do this (or any other sound idea that
> > they really want to do). I am sure that the initial discussion with the
> > mentor can always lead to a project plan that maintains a good balance
> > between being useful and being interesting.
>
> Hi,
>
> thanks for your comments. What I will do is, I will add the task to the
> page with the understanding that other project ideas will have
> precedence if there are applicants for them.
>
> I guess I will also have a closer look on Page Extensions. I'd rather
> not use Lua for this because 1. this would indeed mean introducing
> another language for specifying things in forms, 2. MW itself does not
> support Lua yet and 3. I simply do not have any experience with it. Of
> course, the whole thing would need to be discussed with the student and
> the result could well be to go for Lua anyway.
>
> Cheers,
> Stephan
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Semediawiki-user mailing list
> Semediawiki-user@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>



-- 
WikiWorks · MediaWiki Consulting · http://wikiworks.com