Markus, I'll put in my humble feature request:
Doesn't have to be 1.4, but at some point it would be spectacular to be able to query Geographic coordinates type values...in particular I'm thinking of being able to query for values within a "bounding box", by defining two corners of a rectangle, and have the query only return values within that rectangle. This would make it possible for Semantic Layers or other GIS type extensions to tremendously increase scalability. GIS clients can usually request data for only the area(s) currently being viewed, and if this capability was available, I could send back only that subset of results--allowing a wiki to efficiently serve out a much larger geographic data set (right now I have to send the entire, global set of points on any request). I can think of a couple of other similar capabilities...like return points within a radius of a location, or sorting by proximity...but the above would make me happy. And for my purposes, I'd be happy if it was only available in the API, and didn't have to have a corresponding text query syntax. (Or is there a way to do this already that I'm just not aware of?) Thanks! -Matt On Sep 8, 2008, at 11:07 AM, Markus Krötzsch wrote: > Hi all, > > SMW 1.3 is out and it is time to make plans for the next major > release. Our > intention is to release SMW 1.4 at Nov 17 2008, with a possible > release > candidate as early as Oct 25. Of course, minor updates for 1.3 might > appear > in between as needed for fixing bugs. > > > Currently, we intend to look at the following topics for SMW 1.4: > > * SMW-Parsing process. Various problems with SMW relate to the way > in which we > pass around data during runs of MediaWiki. We would like to re-write > this to > have a more stable behaviour throughout. > > * Improved Type:Date, with support for a broader range of dates and > internationalised inputs. > > * Support for sub-concept relationships (just like sub-category > relationships) > and for the use of concepts in concepts -- if I can get it working. > I do not > promiss inverses here yet, but I might have another look at their > implementation too. > > * Make SMW more extendable with new "special properties", so that > extension > providers can bring their own pre-defined properties. This might be > the > required step to get DPL features into SMW, and we will also look at > this. > > * Cleaner and (if possible) shorter core code. Our new extension > package > SemanticResultFormats will be used as the new home for some of the > more > complex SMW output formats, such as Timeline (of course there will > be a > synchronised release of this extension to ensure seamless upgrading). > > * Alternative input methods. We already presented some first > prototypes of new > input methods #set and #declare. We will further look into improving > those. > > This is a tentative list that may be modified as we go forward. I > will send a > separate mails to the developers' list regarding any internal > changes this > entails. We expect major internal changes that require updates in > extensions, > so upgrading SMW from SVN might be somewhat dangerous within the > next two > months. I will send this warning again before I start major changes. > > > Finally, there are some tasks I know we cannot address, but which we > would > like to support if someone steps forward to take the lead: > > * PostgreSQL support for SMW. We know that it does not work right > now, but it > is surely doable if someone using Postgres comes along to help. > > * A better SMW installation/upgrade interface. We would like to have > something > like MediaWiki's config (the thing you call for setup) for SMW too. In > particular, this should be able to act as a web-interface to some of > the core > maintenance functions. This could be viewed as a re-implementation of > Special:SMWAdmin. > > * Help in internationalising parts of SMW that are not messages. We > still use > special files for keeping the names of, e.g., datatypes. It would be > great if > someone could pursue what better options there might be. Maybe files > like we > use them can be integrated with BetaWiki (our wonderful translation > community), or maybe we can establish a "fake extension" for > translating > those, and importing the translations into SMW-format with some > script. > Creative ideas are wanted. > > > There are many other ideas that one could realise in SMW extensions. > If you > still feel that some relevant feature request to the SMW *core* is not > mentioned here at all (I may have forgotten it), then please feel > free to say > so. I did not see any other major requests in Bugzilla. > > Cheers, > > Markus > > > -- > Markus Krötzsch > Semantic MediaWiki http://semantic-mediawiki.org > http://korrekt.org [EMAIL PROTECTED] > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
