First of all I should say that I greatly appreciate Yaron's and others' contributions to Forms, SMW, and related extensionsimmensely and believe they're quite powerful tools as they are right now.But I also agree with John's sentiments that (on the assumption SMW needs to be competitive to turnkey solutions) SMW/Forms is great at doing a lot of stuff well but can sometimes be inadequate at the "deep dive" applications which require more powerful features. There have been many other times where a feature is "sort of" supported if you go about implementing it in a non-intuitive way.

I think that we as a community of users and developers ought to do a better job of collecting all of these kinds of missing features or functionality requiring hackish solutions so that we can start to see where the gaps are in the tools. I think it would be better for us all if more people were invested in the direction of the SMW extensions.

So having said that, Yaron do you have any ideas about the best way to publicly collect feature requests like John's, and do you have any thoughts on how to involve users in developing a "roadmap" for the extensions?

- Alex

On Tue, Aug 17, 2010 at 3:35 PM, John Arrowwood <> wrote:
Let's take a look at the Semantic MediaWiki FAQ:
What are the alternatives to SMW?

We truly believe that there's no other software yet, either free or
proprietary, that enables flexible, collaborative data structures in the way
that Semantic MediaWiki does. [snip]

In the big picture, the real competitor to Semantic MediaWiki is every
usage-specific so-called "turnkey <>"
application meant to store a specific type of data. We would like to see the
users of many of these applications consider switching to SMW as a cheap,
flexible alternative.

So, if you want Semantic MediaWiki to be able to compete with 'turnkey'
applications, you are going to have to make it capable of competing. I've
not only USED a lot of those 'turnkey' applications, I've been on the
development teams that have CREATED several of them.

Don't get me wrong, I agree that sometimes a person's idea of of how to go
about doing something is not necessarily the "right" way of doing it. But
in this case, you are saying that it can't be done, and moreover doesn't
NEED to be done.

If you seriously want SMW to be a viable alternative to "turnkey"
applications, it has a lot of features that have to be added. A more
powerful query language that can support calculated output is one.
Dependent fields in forms is another. Something that a real developer can
actually build stuff on top of without pulling their hair out is probably
the biggest.

So, there may not be a solution to my immediate problem. I'm cool with
that, this is a work in progress. But seriously, calculated fields needs to
get on the roadmap for the future. That is a big, gaping hole in SMW, one
that if it were plugged would make life a whole lot easier for a lot of

-- John

On Tue, Aug 17, 2010 at 11:03 AM, Yaron Koren <> wrote:

> Hi,
> Sorry, what I meant was just that, at this point in time in the development
> of SMW, SF and the rest, when there are feature requests that are unusual in
> some way, my experience is that they can usually be solved more easily, and
> in a nicer way, with either changes to the data structure, or an alternate
> approach. Not always, but usually.
> In your case, given that I now know what you're trying to do (make a
> dropdown for forms in an "edit category" form), I can suggest a good
> alternative: you can use "autocomplete on namespace" instead - it'll show
> autocompletion instead of a dropdown, but on the other hand, if you use it
> with the "combobox" input type (not available yet in SF, but coming, I
> believe, later this week :) ), it'll function quite a bit like a dropdown.
> Though even without the combobox, I'd say that that's probably the best
> alternative.
> To the general philosophical issue - every software application ever
> written lacks features that it would be potentially useful to have; that's
> just the nature of software (or of life, really).
> -Yaron
> On Tue, Aug 17, 2010 at 8:58 AM, John Arrowwood <> wrote:
>> What a very interesting response. Let me see if I have this straight:
>> You can't think of any good reason why someone would want to do something,
>> and when someone says they want to, your reaction is to attack their choice
>> of organizing their data? I think the problem may be that you are still
>> thinking wiki, whereas I'm using MediaWiki as a platform for developing a
>> data management system.
>> So, what is the actual place where I'm trying to do this? I created a
>> Form to help edit Category pages. On the form, I put a dropdown which lists
>> all of the Structured Documents defined in the system. If the user selects
>> a structured document, then the template looks up everything it needs to
>> know from the Structured Document definition page. Likewise, there is a
>> dropdown that lists all of the forms in the system, so you can select the
>> form to use to edit pages in that category (if you didn't select a
>> structured document). The purpose of all of this is to make it easier for
>> non-technical users to define/edit categories.
>> But the query for forms returns everything looking like:
>> [[:Form:xyz|Form:xyz]], which means that is what shows up in the dropdown.
>> What SHOULD show up in the dropdown is "xyz", as that is all the user needs
>> to see.
>> But in general, I can think of a million reasons why you would need to
>> populate a dropdown with something other than raw page names.
>> 1. A list of users, displayed as Last Name, First
>> 2. A list of open defects, showing defect ID number followed by the
>> summary
>> 3. All open/active User Stories, listing the user story text
>> 4. A list of teams, taken from their team pages
>> Bottom-line: There is a very real need to do this kind of thing.
>> Which means that being "out of luck" means that Semantic MediaWiki is not
>> really ready for prime-time. Is that really the message you want to send to
>> the world?
>> On Mon, Aug 16, 2010 at 8:05 PM, Yaron Koren <> wrote:
>>> Hi,
>>> No, you can't do any of these things, so I guess you're out of luck.
>>> Personally, I think the fact that you're asking about these might
>>> indicate a non-ideal data structure, which is why I was asking about data
>>> structure before; but that's a matter of opinion.
>>> -Yaron
>>> On Mon, Aug 16, 2010 at 6:30 PM, John Arrowwood <>wrote:
>>>> The data structure is not important. What is important is that I want
>>>> to return something other than a page name. The current method of using a
>>>> concept as inputs to a dropdown does not accept anything other than a page
>>>> name. Only the page names are used to populate the dropdown, as best as I
>>>> can tell...
>>>> Imagine it like this: Suppose you had a collection of pages, all in the
>>>> same category. Suppose you wanted to have a dropdown where the values are
>>>> the page names, but converted to upper case. How would you do that?
>>>> How about if you had a collection of pages and sub-pages, and you wanted
>>>> to return only the sub-page name, without the base page? How would you do
>>>> that? So if you had "foo/bar" and "foo/blip" and "foo/goo", and you wanted
>>>> the dropdown to include the values "bar" and "blip" and "goo". How would
>>>> you do that?
>>>> Or if you had a collection of pages in a particular namespace (other
>>>> than the main namespace), and because it is redundant to show the namespace
>>>> name over and over again, you want to show the page name without the
>>>> namespace. Again, the contents of the dropdown should be populated from a
>>>> query, but the actual appearance of each item should be something other than
>>>> the actual page names. It might be, for example, an attribute on the page,
>>>> or a function executed against the page name.
>>>> That is the root of the problem. I tried everything I could find to be
>>>> able to make that happen. The closest thing I could come up with was
>>>> putting a query on the property page that used a template to control the
>>>> allowed values. But as you yourself said, then it doesn't update the values
>>>> unless you 'edit' the property page. That is not a viable alternative.
>>>> Neither is having to 'purge' the property page.
>>>> So, how does one put user-friendly values in dropdowns that are the
>>>> result of a query? Or can you?
>>>> On Mon, Aug 16, 2010 at 5:34 PM, Yaron Koren <> wrote:
>>>>> Hi Alex,
>>>>> John - in a sense, this extension might be helpful for you as well;
>>>>> though I'm always sure there's a better way for you to do whatever it is
>>>>> you're trying to do; though, not knowing your data structure, I don't know
>>>>> what that is.
>>>>> -Yaron
>>>>> On Mon, Aug 16, 2010 at 1:14 PM, Alex Kozak <
>>>>>> wrote:
>>>>>> Has there been any discussion about ways around the data update issue?
>>>>>> Maybe there could be a way for SMW to run the data repair/upgrade in the
>>>>>> background? I've run into this annoyance countless times. It would be nice
>>>>>> not to have to turn off page caching for the whole wiki.
>>>>>> AK
>>>>>> On Mon, Aug 16, 2010 at 10:05 AM, Yaron Koren <>wrote:
>>>>>>> Hi John,
>>>>>>> That doesn't sound like a defect - regardless of what you see on the
>>>>>>> property page, the actual semantic data (allowed values, in this
>>>>>>> case)
>>>>>>> doesn't get updated until there's some sort of update action taken,
>>>>>>> like a
>>>>>>> page save.
>>>>>>> In any case, that's not the ideal way to do it - you should instead
>>>>>>> define
>>>>>>> an SMW "concept" that holds that query, and then use either "values
>>>>>>> from
>>>>>>> concept" or "autocomplete on concept" in the form input (probably the
>>>>>>> former).
>>>>>>> -Yaron
>>>>>>> On Mon, Aug 16, 2010 at 12:50 PM, John Arrowwood <>
>>>>>>> wrote:
>>>>>>> > I have a sequence of pages that all have a common base page,
>>>>>>> "Structured
>>>>>>> > Documents". So, for example, I have Structured Documents/Term for
>>>>>>> the page
>>>>>>> > that has the definition of a glossary Term.
>>>>>>> >
>>>>>>> > I created a property. The definition of that property includes a
>>>>>>> query
>>>>>>> > that
>>>>>>> > returns all of those structured documents, listing only their name
>>>>>>> without
>>>>>>> > the Structured Documents prefix. The idea was that the property
>>>>>>> will be a
>>>>>>> > dropdown on the appropriate form which shows a cleaned-up version
>>>>>>> of the
>>>>>>> > page names.
>>>>>>> >
>>>>>>> > The intention is that as soon as I added a new Structured Document,
>>>>>>> the
>>>>>>> > property would update its 'allowed' list, and the new document
>>>>>>> would appear
>>>>>>> > in the dropdown.
>>>>>>> >
>>>>>>> > In reality, I have to go to the page for that property, make a
>>>>>>> meaningless
>>>>>>> > change, then click Save in order for the change to be picked up.
>>>>>>> Even
>>>>>>> > though I can go to the page, click Purge, and see the new item in
>>>>>>> the list,
>>>>>>> > that alone is not enough. I have to edit and save before the new
>>>>>>> item(s)
>>>>>>> > appear in the dropdown of a form.
>>>>>>> >
>>>>>>> > So the defect is that even though you view the property page and
>>>>>>> see the
>>>>>>> > list of allowed values, the form is not picking up the new list of
>>>>>>> allowed
>>>>>>> > values.
>>>>>>> >
>>>>>>> > However, the real NEED here is a way of associating a form on a
>>>>>>> page with a
>>>>>>> > queried list of values. Unfortunately, I have tried in vain to do
>>>>>>> that.
>>>>>>> > If
>>>>>>> > I put a template call in the default= part of the field definition,
>>>>>>> it
>>>>>>> > isn't
>>>>>>> > treated as a template, and so the user sees it as a template, not
>>>>>>> as a list
>>>>>>> > of values.
>>>>>>> >
>>>>>>> > What is the proper way of accomplishing this goal?
>>>>>>> >
>>>>>>> > --
>>>>>>> > John Arrowwood
>>>>>>> > John (at) Irie (dash) Inc (dot) com
>>>>>>> > John (at) Arrowwood Photography (dot) com
>>>>>>> > John (at) Hanlons Razor (dot) com
>>>>>>> > --
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> > This email is sponsored by
>>>>>>> >
>>>>>>> > Make an app they can't live without
>>>>>>> > Enter the BlackBerry Developer Challenge
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > Semediawiki-user mailing list
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> --
>>>>>>> WikiWorks MediaWiki Consulting
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> This email is sponsored by
>>>>>>> Make an app they can't live without
>>>>>>> Enter the BlackBerry Developer Challenge
>>>>>>> _______________________________________________
>>>>>>> Semediawiki-user mailing list
>>>>>> --
>>>>>> Alex Kozak
>>>>>> Program Assistant
>>>>>> Creative Commons
>>>>> --
>>>>> WikiWorks MediaWiki Consulting
>>>> --
>>>> John Arrowwood
>>>> John (at) Irie (dash) Inc (dot) com
>>>> John (at) Arrowwood Photography (dot) com
>>>> John (at) Hanlons Razor (dot) com
>>>> --
>>> --
>>> WikiWorks MediaWiki Consulting
>>> --
>>> John Arrowwood
>>> John (at) Irie (dash) Inc (dot) com
>>> John (at) Arrowwood Photography (dot) com
>>> John (at) Hanlons Razor (dot) com
>>> --
>>> <>
> --
> WikiWorks MediaWiki Consulting

John Arrowwood
John (at) Irie (dash) Inc (dot) com
John (at) Arrowwood Photography (dot) com
John (at) Hanlons Razor (dot) com
This email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
Semediawiki-user mailing list

Alex Kozak
Program Assistant
Creative Commons