From: Markus <ma...@ai...> - 2007-11-06 10:47:38
|
Hi all, the next release candidate for SMW1.0 is now available for download. It bri= ngs=20 mostly bugfixes to problems encountered with RC1, but also has some new=20 features. The major changes are: * More liberal parsing for geographic coordinates, most user inputs accepte= d=20 now. * Improved URL datatype: better linking behaviour, tolerant towards=20 Unicode-URLs. * Significantly improved performance for RDF export. * Complete translations for Fr, Zh-tw, and Zh-ch added (thanks to =20 Pierre Matringe and Roc Michael). Cheers, Markus =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Sergey C. <sem...@an...> - 2007-11-06 14:52:00
|
Markus, First of all, great job! I can't wait to have less bugs and going to upgrad= e right away! The other issue that I'm having is {{#ask}} parser function - not having it stops almost all of my development. It's probably the most anticipated feature right now. Do you have any timeline or at least defined approach to it? Thank you, Sergey On Nov 6, 2007 5:47 AM, Markus Kr=F6tzsch <ma...@ai...> wrote= : > Hi all, > > the next release candidate for SMW1.0 is now available for download. It > brings > mostly bugfixes to problems encountered with RC1, but also has some new > features. The major changes are: > > * More liberal parsing for geographic coordinates, most user inputs > accepted > now. > * Improved URL datatype: better linking behaviour, tolerant towards > Unicode-URLs. > * Significantly improved performance for RDF export. > * Complete translations for Fr, Zh-tw, and Zh-ch added (thanks to > Pierre Matringe and Roc Michael). > > Cheers, > > Markus > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > > ------------------------------------------------------------------------- > 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-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: cnit <cn...@un...> - 2007-11-06 15:06:23
|
> The other issue that I'm having is {{#ask}} parser function - not > having it stops almost all of my development. It's probably the most > anticipated feature right now. Do you have any timeline or at least > defined approach to it? I guess that "RC" thing means - "The development of major features is temporarily frozen. Only small bugfixes are accepted". That approach is used to make the code more stable. I am myself missing parser function badly, but I guess that complaining too often won't speed up the development, rather bore the developers.. I am investigating my own upgrade, too. My temporarily solution for dynanical queries will be small patch I plan to make unpublished - just simply %FUNCTION_NAME% inside query param will be replaced with result of the call to according PHP function, instead of template. Should be easy to implement (with some security restrictions, of course - though my wiki is not public). When the function will be available, I'll switch to these. Dmitriy |
From: Sergey C. <sem...@an...> - 2007-11-06 17:35:43
|
My "complaint" was not about the availability of the feature itself, but about not knowing if I should expect it in SMW 1.0 release or not - your email is first message about any timeline that is available to me. And it seems that the answer is 'no'. I'm not sure if having hardcoded workarounds works for me because I'm planning to have quite a few parser functions within templates and adding custom PHP functions for all of the cases is just impossible. It'll be greate if there was some place on ontoworld.org that described plans and timelines - this page: http://ontoworld.org/wiki/Semantic_MediaWiki_development_activities is not updated to often, unfortunately. Sergey On Nov 6, 2007 10:01 AM, cnit <cn...@un...> wrote: > > The other issue that I'm having is {{#ask}} parser function - not > > having it stops almost all of my development. It's probably the most > > anticipated feature right now. Do you have any timeline or at least > > defined approach to it? > I guess that "RC" thing means - "The development of major features is > temporarily frozen. Only small bugfixes are accepted". That approach > is used to make the code more stable. > > I am myself missing parser function badly, but I guess that > complaining too often won't speed up the development, rather bore the > developers.. > > I am investigating my own upgrade, too. My temporarily solution for > dynanical queries will be small patch I plan to make unpublished - > just simply %FUNCTION_NAME% inside query param will be replaced > with result of the call to according PHP function, instead of template. > Should be easy to implement (with some security restrictions, of course > - though my wiki is not public). > > When the function will be available, I'll switch to these. > Dmitriy > > > ------------------------------------------------------------------------- > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Markus <ma...@ai...> - 2007-11-06 16:23:54
|
On Dienstag, 6. November 2007, cnit wrote: > > The other issue that I'm having is {{#ask}} parser function - not > > having it stops almost all of my development. It's probably the most > > anticipated feature right now. Do you have any timeline or at least > > defined approach to it? > > I guess that "RC" thing means - "The development of major features is > temporarily frozen. Only small bugfixes are accepted". That approach > is used to make the code more stable. No, not quite. Two more features are scheduled for SMW1.0 final: one (as yo= u=20 know) is {{#ask}}, and the other is the listing of subproperties on propert= y=20 pages. We know that traditionally one would do RCs together with a feature= =20 freeze, but in a wiki one can certainly have optional features released als= o=20 if they are less well-tested. The reasons why we have started releasing RCs are: * Some people started asking us whether the project was still alive ;-) * The developers of the Halo extension asked for an early release, so that= =20 they could release some code compatible with a fixed version of SMW. * More testing cannot hurt. The RC-process does not slow down our work on the aforementioned features -= =2D=20 it would have been slow anyway. > > I am myself missing parser function badly, but I guess that > complaining too often won't speed up the development, rather bore the > developers.. Well, you can always add some further pressure, but our development activit= y=20 still is subject to various constraints that are outside our control (jobs,= =20 lives, ...) ;-) But maybe, since we are over it, we can start some design discussions about= =20 {{#ask...}}. In particular, parser functions have a slightly different styl= e=20 of parameters than parser hooks (<ask>). Our current <ask> has three parts: (1) the query conditions, (2) multiple print statements, (3) a variable set of parameters. Currently (1) and (2) can be mixed, although the position of print statemen= ts=20 relative to the query conditions has no effect. Moving to a parser function= =20 seems to be a good opportunity to revise some of this design, e.g. by simpl= y=20 making the print statements a separate parameter. In {{#ask..}}, everything= =20 must be passed as a parameter anyway, so separating (1) and (2) is no=20 complication. How should an example query look like? Her is a suggested=20 example transformation: <ask format=3D"table" limit=3D"12"> [[Category:Person]] [[lives in::Europe]]=20 [[lives in::*]] [[birthday::*|day of birth]]=20 [[height::*m=B2|size]] </ask> becomes {{#ask| format=3Dtable| limit =3D 12| ?lives in| ?birthday =3D day of birth| ?height#m=B2 =3D size| [[Category:Person]] [[lives in::Europe]] }} Basic points: * The query is always the last parameter. * No | appear unless they are used as separators between parameters. * Printouts start with "?" * All the known printout modifications somehow work, but in different synta= x. * We implicitly block "=3D" in property names (should we care?) Some of this syntax is not essential, but one must be careful not to collid= e=20 with MediaWiki syntax. <ask> would of course continue to work in any case,= =20 but {{#ask}} would become the suggested method in the future. I guess the main point of discussion would be the printout-parameters. Many= =20 variations are possible, and comments are welcome. > > I am investigating my own upgrade, too. My temporarily solution for > dynanical queries will be small patch I plan to make unpublished - > just simply %FUNCTION_NAME% inside query param will be replaced > with result of the call to according PHP function, instead of template. > Should be easy to implement (with some security restrictions, of course > - though my wiki is not public). > > When the function will be available, I'll switch to these. Yes, that would be a very versatile mechanism indeed. Cheers, Markus > Dmitriy > > > ------------------------------------------------------------------------- > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Yaron K. <ya...@gm...> - 2007-11-06 18:05:58
|
I think that's a great format for the {{ask}} parser function - it nicely separates data from presentation; which are somewhat mixed together in current inline queries. Also, this is unrelated, but I discovered yesterday that inline queries in SMW 1.0 can handle redirected pages (pages for which a property links to a page that redirects to them now show up in query results), which is a great feature. Thanks! -Yaron On Nov 6, 2007 11:20 AM, Markus Kr=F6tzsch <ma...@ai...> wrot= e: > On Dienstag, 6. November 2007, cnit wrote: > > > The other issue that I'm having is {{#ask}} parser function - not > > > having it stops almost all of my development. It's probably the most > > > anticipated feature right now. Do you have any timeline or at least > > > defined approach to it? > > > > I guess that "RC" thing means - "The development of major features is > > temporarily frozen. Only small bugfixes are accepted". That approach > > is used to make the code more stable. > > No, not quite. Two more features are scheduled for SMW1.0 final: one (as > you > know) is {{#ask}}, and the other is the listing of subproperties on > property > pages. We know that traditionally one would do RCs together with a featur= e > freeze, but in a wiki one can certainly have optional features released > also > if they are less well-tested. > > The reasons why we have started releasing RCs are: > > * Some people started asking us whether the project was still alive ;-) > * The developers of the Halo extension asked for an early release, so tha= t > they could release some code compatible with a fixed version of SMW. > * More testing cannot hurt. > > The RC-process does not slow down our work on the aforementioned features > -- > it would have been slow anyway. > > > > > I am myself missing parser function badly, but I guess that > > complaining too often won't speed up the development, rather bore the > > developers.. > > Well, you can always add some further pressure, but our development > activity > still is subject to various constraints that are outside our control > (jobs, > lives, ...) ;-) > > But maybe, since we are over it, we can start some design discussions > about > {{#ask...}}. In particular, parser functions have a slightly different > style > of parameters than parser hooks (<ask>). Our current <ask> has three > parts: > > (1) the query conditions, > (2) multiple print statements, > (3) a variable set of parameters. > > Currently (1) and (2) can be mixed, although the position of print > statements > relative to the query conditions has no effect. Moving to a parser > function > seems to be a good opportunity to revise some of this design, e.g. by > simply > making the print statements a separate parameter. In {{#ask..}}, > everything > must be passed as a parameter anyway, so separating (1) and (2) is no > complication. How should an example query look like? Her is a suggested > example transformation: > > <ask format=3D"table" limit=3D"12"> > [[Category:Person]] [[lives in::Europe]] > [[lives in::*]] > [[birthday::*|day of birth]] > [[height::*m=B2|size]] > </ask> > > becomes > > {{#ask| > format=3Dtable| > limit =3D 12| > ?lives in| > ?birthday =3D day of birth| > ?height#m=B2 =3D size| > [[Category:Person]] [[lives in::Europe]] > }} > > Basic points: > * The query is always the last parameter. > * No | appear unless they are used as separators between parameters. > * Printouts start with "?" > * All the known printout modifications somehow work, but in different > syntax. > * We implicitly block "=3D" in property names (should we care?) > > Some of this syntax is not essential, but one must be careful not to > collide > with MediaWiki syntax. <ask> would of course continue to work in any case= , > but {{#ask}} would become the suggested method in the future. > > I guess the main point of discussion would be the printout-parameters. > Many > variations are possible, and comments are welcome. > > > > > I am investigating my own upgrade, too. My temporarily solution for > > dynanical queries will be small patch I plan to make unpublished - > > just simply %FUNCTION_NAME% inside query param will be replaced > > with result of the call to according PHP function, instead of template. > > Should be easy to implement (with some security restrictions, of course > > - though my wiki is not public). > > > > When the function will be available, I'll switch to these. > > Yes, that would be a very versatile mechanism indeed. > > Cheers, > > Markus > > > Dmitriy > > > > > > > ------------------------------------------------------------------------- > > 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 > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > > ------------------------------------------------------------------------- > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > |
From: Sergey C. <sem...@an...> - 2007-11-06 18:11:52
|
Markus, thank you for the follow-up! It's great to know that {{#ask}} is scheduled for 1.0 release! I'm happy to participate in architectural discussion. Here're some thoughts on the subject: 1. it seems to be to restricting on query language to remove pipes and equal signs from it - who knows, maybe you'll want to have '|' character= s in OR-like statements or '=3D' in filtering statements. 2. I'm not sure if it makes a lot of sense to change the format of query language from old version to new one I can propose, if not very elegant, but a solution - make a query to be a last parameter and let's have a name for it, e.g. 'query' - all parameters after the one that start with ~/^query\s+=3D/ will get joined to it using a pipe. In your example: <ask format=3D"table" limit=3D"12"> [[Category:Person]] [[lives in::Europe]] [[lives in::*]] [[birthday::*|day of birth]] [[height::*m=B2|size]] </ask> will get converted to: {{#ask:format=3Dtable|limit=3D12|query=3D [[Category:Person]] [[lives in::Europe]] [[lives in::*]] [[birthday::*|day of birth]] [[height::*m=B2|size]] }} Here's the pseudo-code for this: function askParserFunc (&$parser) { $params =3D func_get_args(); array_shift($params); # first one is parser - we don't need it $query =3D ''; $queryfound =3D false; foreach ($params as $param) { if (!$queryfound) { if (preg_match('/^query\s+=3D/', $param)) { $query =3D preg_replace('/^query\s+=3D/', '', $param); // all params after this one will get appended to $query $queryfound =3D true; continue; } ... process all the rest of params ... } else { $query.=3D'|'.$param; } } ... do actual inline query work ... } I didn't test the code, but I used func_get_args approach and it worked for me. This can be used if you keep current syntax or introduce new one. What do you think of this approach. Sergey On Nov 6, 2007 11:20 AM, Markus Kr=F6tzsch <ma...@ai...> wrot= e: > On Dienstag, 6. November 2007, cnit wrote: > > > The other issue that I'm having is {{#ask}} parser function - not > > > having it stops almost all of my development. It's probably the most > > > anticipated feature right now. Do you have any timeline or at least > > > defined approach to it? > > > > I guess that "RC" thing means - "The development of major features is > > temporarily frozen. Only small bugfixes are accepted". That approach > > is used to make the code more stable. > > No, not quite. Two more features are scheduled for SMW1.0 final: one (as > you > know) is {{#ask}}, and the other is the listing of subproperties on > property > pages. We know that traditionally one would do RCs together with a featur= e > freeze, but in a wiki one can certainly have optional features released > also > if they are less well-tested. > > The reasons why we have started releasing RCs are: > > * Some people started asking us whether the project was still alive ;-) > * The developers of the Halo extension asked for an early release, so tha= t > they could release some code compatible with a fixed version of SMW. > * More testing cannot hurt. > > The RC-process does not slow down our work on the aforementioned features > -- > it would have been slow anyway. > > > > > I am myself missing parser function badly, but I guess that > > complaining too often won't speed up the development, rather bore the > > developers.. > > Well, you can always add some further pressure, but our development > activity > still is subject to various constraints that are outside our control > (jobs, > lives, ...) ;-) > > But maybe, since we are over it, we can start some design discussions > about > {{#ask...}}. In particular, parser functions have a slightly different > style > of parameters than parser hooks (<ask>). Our current <ask> has three > parts: > > (1) the query conditions, > (2) multiple print statements, > (3) a variable set of parameters. > > Currently (1) and (2) can be mixed, although the position of print > statements > relative to the query conditions has no effect. Moving to a parser > function > seems to be a good opportunity to revise some of this design, e.g. by > simply > making the print statements a separate parameter. In {{#ask..}}, > everything > must be passed as a parameter anyway, so separating (1) and (2) is no > complication. How should an example query look like? Her is a suggested > example transformation: > > <ask format=3D"table" limit=3D"12"> > [[Category:Person]] [[lives in::Europe]] > [[lives in::*]] > [[birthday::*|day of birth]] > [[height::*m=B2|size]] > </ask> > > becomes > > {{#ask| > format=3Dtable| > limit =3D 12| > ?lives in| > ?birthday =3D day of birth| > ?height#m=B2 =3D size| > [[Category:Person]] [[lives in::Europe]] > }} > > Basic points: > * The query is always the last parameter. > * No | appear unless they are used as separators between parameters. > * Printouts start with "?" > * All the known printout modifications somehow work, but in different > syntax. > * We implicitly block "=3D" in property names (should we care?) > > Some of this syntax is not essential, but one must be careful not to > collide > with MediaWiki syntax. <ask> would of course continue to work in any case= , > but {{#ask}} would become the suggested method in the future. > > I guess the main point of discussion would be the printout-parameters. > Many > variations are possible, and comments are welcome. > > > > > I am investigating my own upgrade, too. My temporarily solution for > > dynanical queries will be small patch I plan to make unpublished - > > just simply %FUNCTION_NAME% inside query param will be replaced > > with result of the call to according PHP function, instead of template. > > Should be easy to implement (with some security restrictions, of course > > - though my wiki is not public). > > > > When the function will be available, I'll switch to these. > > Yes, that would be a very versatile mechanism indeed. > > Cheers, > > Markus > > > Dmitriy > > > > > > > ------------------------------------------------------------------------- > > 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 > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > |
From: Peter C. <pet...@pb...> - 2007-11-17 20:02:22
|
Hello Markus, On Tuesday, November 6, 2007, 4:20:53 PM, you wrote: MK> On Dienstag, 6. November 2007, cnit wrote: >> > The other issue that I'm having is {{#ask}} parser function - not >> > having it stops almost all of my development. It's probably the most >> > anticipated feature right now. Do you have any timeline or at least >> > defined approach to it? [extra stuff edited out] >> I am myself missing parser function badly, but I guess that >> complaining too often won't speed up the development, rather bore the >> developers.. MK> Well, you can always add some further pressure, but our development act= ivity MK> still is subject to various constraints that are outside our control (j= obs, MK> lives, ...) ;-) MK> But maybe, since we are over it, we can start some design discussions a= bout MK> {{#ask...}}. In particular, parser functions have a slightly different = style MK> of parameters than parser hooks (<ask>). Our current <ask> has three pa= rts: MK> (1) the query conditions, MK> (2) multiple print statements, MK> (3) a variable set of parameters. MK> Currently (1) and (2) can be mixed, although the position of print stat= ements MK> relative to the query conditions has no effect. Moving to a parser func= tion MK> seems to be a good opportunity to revise some of this design, e.g. by s= imply MK> making the print statements a separate parameter. In {{#ask..}}, everyt= hing MK> must be passed as a parameter anyway, so separating (1) and (2) is no MK> complication. How should an example query look like? Her is a suggested MK> example transformation: MK> <ask format=3D"table" limit=3D"12"> MK> [[Category:Person]] [[lives in::Europe]]=20 MK> [[lives in::*]] MK> [[birthday::*|day of birth]]=20 MK> [[height::*m=B2|size]] MK> </ask> MK> becomes MK> {{#ask| MK> format=3Dtable| MK> limit =3D 12| MK> ?lives in| MK> ?birthday =3D day of birth| MK> ?height#m=B2 =3D size| MK> [[Category:Person]] [[lives in::Europe]] MK> }} MK> Basic points: MK> * The query is always the last parameter. MK> * No | appear unless they are used as separators between parameters. MK> * Printouts start with "?" MK> * All the known printout modifications somehow work, but in different s= yntax. MK> * We implicitly block "=3D" in property names (should we care?) MK> Some of this syntax is not essential, but one must be careful not to co= llide MK> with MediaWiki syntax. <ask> would of course continue to work in any ca= se, MK> but {{#ask}} would become the suggested method in the future. MK> I guess the main point of discussion would be the printout-parameters. = Many MK> variations are possible, and comments are welcome. On Monday, November 12, 2007, 9:31:03 PM, Jim Wilson wrote: JW> Although I am in favor of {{#ask:}} at the earliest possible JW> conveneince, after a cursory look through the code, I'm fairly certain JW> this extension will fail to operate as expected. JW> The first reason is that <ask>, which is an extension tag, will always JW> return fully qualified HTML. The output of a parser function is JW> expected to be wikitext, which will be further processed. The result JW> is that if the output of the {{#ask:}} call contains any links, JW> they'll be HTML links (like <a JW> href=3D"something">something</a>), not JW> wiki text (like [[something]]). When the Parser reads these HTML tags JW> during subsequent processing, it'll convert the '<' and '>' symbols to JW> their entity equivalents '<' and '>' so in the browser you JW> actually see '<a href=3D"...">whatever</a>', not a nice link. JW> The second reason is that one of the huge benefits of having an JW> {{#ask:}} parser function is nesting. The idea that you could JW> {{#ask:something=3D{{#ask:something else}}}}. I'm not sure if SMW JW> supports nested <ask> tags, but if not, this would also be a failure JW> mode of the aforementioned extension. JW> Again, I would like nothing more from SMW than an {{#ask:}} template - JW> which would be a __HUGE__ improvement for advanced use cases, but I JW> don't think that this extension is the answer everyone hopes it is. JW> -- Jim R. Wilson (jimbojw) As Jim notes, when used with {{#ask:}}, all of the Query Printers will need to use wiki formatting rather than HTML, but that should not be too difficult I would have thought. Since Markus is asking about updating the parameter passing conventions for use with queries (especially in relation to Query Printers), I thought I would step in with some suggestions that I have been harbouring for some time. Extra 'top level' parameters =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D "lastsep=3D" Used with "format=3Dlist" to control the separator between the last pair of rows. Currently, if you use "sep=3D", the value you give is used between all rows (including the last pair). Example: format=3Dlist sep=3D",_" lastsep=3D",_or_" "suffix=3D" Used with all formats to add text after everything else (in the same way that "intro" adds text before everything else). Field specific parameters =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When a field has multiple values, they are always formatted with ", " as the separator for "format=3Dlist", "format=3Dul", and "format=3Dol", and always formatted with "<br>" as the separator for "format=3Dtable". This needs to be made more flexible too as I have wikis where some fields might actually have a dozen or more values and I'd really like to format them as a simple comma separated list. In fact you need to be able to format each field independantly of every other field. Currently, the only extra 'field specific' parameter is the alternate name that is displayed. The extra ones I believe would come in useful are: "prefix=3D" and "suffix=3D" Specify text to appear before and after the values for a field. =20 "format=3D" Specify how the values of the field should be displayed. =20 Choices of "list" (with the use of "sep=3D" and "lastsep=3D" options), "ul", "ol", or "template" (with use of "template=3D" option). "link=3D" Specify whether values that refer to other pages should be displayed as links or not. Choices of "yes", or "no". "header=3D" Specify whether or not the field name should be displayed (and if it is displayed: whether it should be displayed as a link) Choices of "link", "show", "hide". "template=3D" Specify the template to use to display the values for the field. The template specified would be able to use any wiki formatting it likes (including creating an embedded table). Example: <ask format=3D"table" limit=3D"12"> [[Category:Person]] [[lives in::Europe]] [[lives in::*||header=3Dhide]] [[birthday::*|day of birth]] [[height::*m=B2|size]] [[friends::*||format=3Dtemplate|template=3DFriendInfo]] [[interests::*||format=3Dul] [[other::*|Other|format=3Dlist|prefix=3D"Some Text:"|lastsep=3D",_or_"|suf= fix=3D.]] </ask> {{#ask: [[Category:Person]] [[lives in::Europe]]| format=3Dtable| limit=3D12| ?lives in=3D:header=3Dhide| ?birthday=3DDay or birth| ?height=3DSize:unit=3Dm=B2| ?friends=3DFriends:format=3Dtemplate:template=3DFriendInfo| ?interests=3DInterests:format=3Dul ?other=3DOther:format=3Dlist:prefix=3D"Some Text:":lastsep=3D",_or_":suffi= x=3D.| }} The use of "template=3D" with "format=3Dlist", "format=3Dul", and "format= =3Dol" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Currently, if your wiki includes any pages that have an "=3D" sign in their title, and you then reference those pages using a relation from another page, or if the page itself is matched by a query, the page link does not display correctly when using "template=3D". This is caused by code like the following in SMWTemplateResultPrinter::getH= TML $wikitext =3D ''; $firstcol =3D true; foreach ($row as $field) { $wikitext .=3D "|"; $first =3D true; while ( ($text =3D $field->getNextWikiText($this->getLinker($firstcol)= )) !=3D=3D false ) { if ($first) { $first =3D false; } else { $wikitext .=3D ', '; } $wikitext .=3D $text; } $firstcol =3D false; } $parserinput .=3D '{{' . $this->m_template . str_replace('=3D','|',= $wikitext) . '}}'; // encode '=3D' for use in templates (templates fail otherwise) Better code would be: $wikitext =3D ''; $firstcol =3D true; $fieldnum =3D 1; foreach ($row as $field) { $wikitext .=3D "|" . $fieldnum . "=3D"; $fieldnum +=3D 1; $first =3D true; while ( ($text =3D $field->getNextWikiText($this->getLinker($firstcol)= )) !=3D=3D false ) { if ($first) { $first =3D false; } else { $wikitext .=3D ', '; } $wikitext .=3D $text; } $firstcol =3D false; } $parserinput .=3D '{{' . $this->m_template . $wikitext . '}}'; This follows Mediawiki's own guidelines for dealing with positional parameters that might have values with an "=3D" sign in them. CSS Styles and "format=3Dtable" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D If you use "format=3Dtable", you have no control over the look of the resulting table (other than by editing SMW_custom.css which then applies to every query on the wiki). It would be nice if we could override SMW_custom.css for individual queries: {{#ask: $table=3D"background-color:#ccffff; border-spacing:0pt; padding: 0pt;"| $th=3D"background-color: #FFEEEE;"| $tr.odd=3D"background-color:#ffccff;"| $tr.even=3D"background-color:#ffffcc;"| $td=3D"padding-left: 5pt; padding-right: 5pt"| ... }} Which would be expanded to: {| class=3D"smwtable" id=3D"querytable#" style=3D"background-color:#ccffff;= border-spacing:0pt; padding: 0pt;" |- ! style=3D"background-color: #FFEEEE;" | Header |- style=3D"background-color:#ffccff;" | style=3D"padding-left: 5pt; padding-right: 5pt" | Odd Row |- style=3D"background-color:#ffffcc;" | style=3D"padding-left: 5pt; padding-right: 5pt" | Even Row |- style=3D"background-color:#ffccff;" | style=3D"padding-left: 5pt; padding-right: 5pt" | Odd Row |- style=3D"background-color:#ffffcc;" | style=3D"padding-left: 5pt; padding-right: 5pt" | Even Row ... |} -- Peter Clements |
From: Markus <ma...@ai...> - 2007-11-23 20:23:42
|
On Samstag, 17. November 2007, Peter Clements wrote: > Hello Markus, > <snip> Hi Peter. =46irst of all: thanks for that discussion. I think parameter cleanup/exten= sion=20 in a planned way is truly needed, and a public discussion is a good idea. A= ll=20 of this should probably come with some mechanism for parameter=20 internationalisation and aliasing. I have some comments below. > > As Jim notes, when used with {{#ask:}}, all of the Query Printers will > need to use wiki formatting rather than HTML, but that should not be > too difficult I would have thought. > > Since Markus is asking about updating the parameter passing > conventions for use with queries (especially in relation to Query > Printers), I thought I would step in with some suggestions that I have > been harbouring for some time. > > Extra 'top level' parameters > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > "lastsep=3D" > > Used with "format=3Dlist" to control the separator between the last > pair of rows. > > Currently, if you use "sep=3D", the value you give is used between > all rows (including the last pair). > > Example: > > format=3Dlist sep=3D",_" lastsep=3D",_or_" Agreed. > > "suffix=3D" > > Used with all formats to add text after everything else (in the > same way that "intro" adds text before everything else). Agreed, though this suggests to call "intro" "prefix" instead (needs an ali= as=20 to still allow "intro" for existing wikis). > > Field specific parameters > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > When a field has multiple values, they are always formatted with ", " > as the separator for "format=3Dlist", "format=3Dul", and "format=3Dol", a= nd > always formatted with "<br>" as the separator for "format=3Dtable". This > needs to be made more flexible too as I have wikis where some fields > might actually have a dozen or more values and I'd really like to > format them as a simple comma separated list. In fact you need to be > able to format each field independantly of every other field. Yes, I know of these limitations, and as you already found out, the new for= mat=20 for printout-requests was also motivated by the idea of simplifying such=20 extensions. > > Currently, the only extra 'field specific' parameter is the alternate > name that is displayed. > > The extra ones I believe would come in useful are: > > "prefix=3D" and "suffix=3D" > > Specify text to appear before and after the values for a field. > > "format=3D" > > Specify how the values of the field should be displayed. > > Choices of "list" (with the use of "sep=3D" and "lastsep=3D" options), > "ul", "ol", or "template" (with use of "template=3D" option). > > "link=3D" > > Specify whether values that refer to other pages should be > displayed as links or not. > > Choices of "yes", or "no". > > "header=3D" > > Specify whether or not the field name should be displayed (and if > it is displayed: whether it should be displayed as a link) > > Choices of "link", "show", "hide". > > "template=3D" > > Specify the template to use to display the values for the field. > The template specified would be able to use any wiki formatting it > likes (including creating an embedded table). Basically all agreed, though I fear that even a very good syntax will rende= r=20 these features mostly incomprehensible to normal users. But there is=20 obviously some minimal complexity inherent to the task we want to solve her= e. One more that you did not add: "limit" (sometimes you just don't want more= =20 than a few entries, and maybe [configurable] a link to more results). > > Example: > > <ask format=3D"table" limit=3D"12"> > [[Category:Person]] [[lives in::Europe]] > [[lives in::*||header=3Dhide]] > [[birthday::*|day of birth]] > [[height::*m=B2|size]] > [[friends::*||format=3Dtemplate|template=3DFriendInfo]] > [[interests::*||format=3Dul] > [[other::*|Other|format=3Dlist|prefix=3D"Some > Text:"|lastsep=3D",_or_"|suffix=3D.]] </ask> Actually I do not care much about this one. <ask> will probably die out soo= n=20 enough when {{#ask}} works as expected. So we can avoid further overloading= =20 of MediaWiki link syntax. > > {{#ask: > [[Category:Person]] [[lives in::Europe]]| > format=3Dtable| > limit=3D12| > ?lives in=3D:header=3Dhide| > ?birthday=3DDay or birth| > ?height=3DSize:unit=3Dm=B2| > ?friends=3DFriends:format=3Dtemplate:template=3DFriendInfo| > ?interests=3DInterests:format=3Dul > ?other=3DOther:format=3Dlist:prefix=3D"Some Text:":lastsep=3D",_or_":suf= fix=3D.| > }} Units are currently appended via #, as in ?height#m=B2 =3D Size| Appending parameters via ":" seems feasible as a base syntax. However, I=20 consider supplying another parserfunction as syntactic sugar, e.g. like ?other=3DOther {{#ask-print:format=3Dlist|prefix=3DSome Text:|lastsep=3D,_o= r_| suffix=3D.}}| > > The use of "template=3D" with "format=3Dlist", "format=3Dul", and "format= =3Dol" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Currently, if your wiki includes any pages that have an "=3D" sign in > their title, and you then reference those pages using a relation from > another page, or if the page itself is matched by a query, the page > link does not display correctly when using "template=3D". > > This is caused by code like the following in > SMWTemplateResultPrinter::getHTML > > $wikitext =3D ''; > $firstcol =3D true; > foreach ($row as $field) { > $wikitext .=3D "|"; > $first =3D true; > while ( ($text =3D $field->getNextWikiText($this->getLinker($firstco= l))) > !=3D=3D false ) { if ($first) { > $first =3D false; > } else { > $wikitext .=3D ', '; > } > $wikitext .=3D $text; > } > $firstcol =3D false; > } > $parserinput .=3D '{{' . $this->m_template . str_replace('=3D','|= ', > $wikitext) . '}}'; // encode '=3D' for use in templates (templates fail > otherwise) > > Better code would be: > > $wikitext =3D ''; > $firstcol =3D true; > $fieldnum =3D 1; > foreach ($row as $field) { > $wikitext .=3D "|" . $fieldnum . "=3D"; > $fieldnum +=3D 1; > $first =3D true; > while ( ($text =3D $field->getNextWikiText($this->getLinker($firstco= l))) > !=3D=3D false ) { if ($first) { > $first =3D false; > } else { > $wikitext .=3D ', '; > } > $wikitext .=3D $text; > } > $firstcol =3D false; > } > $parserinput .=3D '{{' . $this->m_template . $wikitext . '}}'; > > This follows Mediawiki's own guidelines for dealing with positional > parameters that might have values with an "=3D" sign in them. Good point. Will soon be implemented this way. > > CSS Styles and "format=3Dtable" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > If you use "format=3Dtable", you have no control over the look of the > resulting table (other than by editing SMW_custom.css which then > applies to every query on the wiki). > > It would be nice if we could override SMW_custom.css for individual > queries: > > {{#ask: > $table=3D"background-color:#ccffff; border-spacing:0pt; padding: 0pt;"| > $th=3D"background-color: #FFEEEE;"| > $tr.odd=3D"background-color:#ffccff;"| > $tr.even=3D"background-color:#ffffcc;"| > $td=3D"padding-left: 5pt; padding-right: 5pt"| > ... > }} > > Which would be expanded to: > > {| class=3D"smwtable" id=3D"querytable#" style=3D"background-color:#ccfff= f; > border-spacing:0pt; padding: 0pt;" > > |- > > ! style=3D"background-color: #FFEEEE;" | Header > > |- style=3D"background-color:#ffccff;" > | style=3D"padding-left: 5pt; padding-right: 5pt" | Odd Row > |- style=3D"background-color:#ffffcc;" > | style=3D"padding-left: 5pt; padding-right: 5pt" | Even Row > |- style=3D"background-color:#ffccff;" > | style=3D"padding-left: 5pt; padding-right: 5pt" | Odd Row > |- style=3D"background-color:#ffffcc;" > | style=3D"padding-left: 5pt; padding-right: 5pt" | Even Row > > ... > > |} Another nice idea. Again this is much easier (saver) for {{#ask }}, since=20 MediaWiki then (hopefully) takes care of possible CSS-XSS attacks. Note tha= t=20 the sorting script (which will, btw., soon be fixed to support non-alphabet= ic=20 columns again) needs to take the "striped" table layout into account, which= =20 it currently doesn't. My only fear is the increasing complexity of all that, but it seems that th= e=20 hacks that people already use to emulate these features are even worse=20 anyway :-/ Markus =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Markus <ma...@ai...> - 2007-11-23 21:01:32
|
And another note: {{#ask}} is in SVN (in a first version). Working example query: {{#ask: [[Category:Country]] [[borders::Nigeria]] | ?population| ?area#km=B2 =3D ''Size''| format=3Dlist| limit =3D 3| link=3Dall| intro=3D<b>Test</b>_| }} Moreover, it is now of course possible to use templates and their params=20 rather freely in {{#ask}}. Actually even some very unreasonable things work= ,=20 but many cool things should also be possible. One real issue might be that= =20 uninitiated users might nest {{#ask}} in order to emulate <q>-subqueries,=20 even though the latter are much more efficient and complete. Of course=20 nesting sometimes is desirable: {{#ask: [[Category:Country]]=20 [[population::>{{#ask:headers=3Dhide|?Population|[[Uganda]]}} ]] | sort=3Dpopulation| ?population }} This indeed works now. Here is what should hopefully work for #ask on SVN: * all printout formats other than "debug" (which still gives some HTML), * all known parameters (though some now are more flexible since you can use= =20 wiki-markup as values), * printout requests with the syntax "? property#unit =3D label", * basic queries, nested queries, value ranges, wildcards, and yet * <ask> should work as it did before (I hope). Here is what certainly does not work: * links to further results don't work in wikitext (we need another URL-sche= me=20 for that, but "external" links may be my first fix), * printouts of Categories do not work via "? Category" yet, * disjunctions in queries obviously do not work yet, since "|" is already=20 taken in templates (Sergey suggested a solution that would require queries = to=20 be the last #ask-parameter, but we may even get around this by providing an= =20 alternative syntax for "||"), * a query with limit 0 might show a broken further results link, * templated and embedded printers may pull annotations into the article whe= re=20 the query is -- this needs some advanced fix as there is currently no way f= or=20 us to distinguish #ask-printed results from the text someone entered=20 directly. I guess there are more things, but at least most of the above should be fix= ed=20 soon. Feel free to try out the devel version (otherwise it's pretty much RC= 2,=20 no updates needed) and let me know what breaks/works/is still missing. Cheers, Markus =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Sergey C. <sem...@an...> - 2007-11-27 06:08:17
|
WOW! Markus, this is great present for being back from vacation! ;) I'll test it on my instances as soon as I'll get some time with computer tomorrow. Sergey On Nov 23, 2007 4:01 PM, Markus Kr=F6tzsch <ma...@ai...> wrot= e: > And another note: {{#ask}} is in SVN (in a first version). > > Working example query: > > {{#ask: [[Category:Country]] [[borders::Nigeria]] | > ?population| > ?area#km=B2 =3D ''Size''| > format=3Dlist| > limit =3D 3| > link=3Dall| > intro=3D<b>Test</b>_| > }} > > Moreover, it is now of course possible to use templates and their params > rather freely in {{#ask}}. Actually even some very unreasonable things > work, > but many cool things should also be possible. One real issue might be tha= t > uninitiated users might nest {{#ask}} in order to emulate <q>-subqueries, > even though the latter are much more efficient and complete. Of course > nesting sometimes is desirable: > > {{#ask: > [[Category:Country]] > [[population::>{{#ask:headers=3Dhide|?Population|[[Uganda]]}} ]] | > sort=3Dpopulation| > ?population > }} > > This indeed works now. > > Here is what should hopefully work for #ask on SVN: > > * all printout formats other than "debug" (which still gives some HTML), > * all known parameters (though some now are more flexible since you can > use > wiki-markup as values), > * printout requests with the syntax "? property#unit =3D label", > * basic queries, nested queries, value ranges, wildcards, and yet > * <ask> should work as it did before (I hope). > > Here is what certainly does not work: > > * links to further results don't work in wikitext (we need another > URL-scheme > for that, but "external" links may be my first fix), > * printouts of Categories do not work via "? Category" yet, > * disjunctions in queries obviously do not work yet, since "|" is already > taken in templates (Sergey suggested a solution that would require querie= s > to > be the last #ask-parameter, but we may even get around this by providing > an > alternative syntax for "||"), > * a query with limit 0 might show a broken further results link, > * templated and embedded printers may pull annotations into the article > where > the query is -- this needs some advanced fix as there is currently no way > for > us to distinguish #ask-printed results from the text someone entered > directly. > > I guess there are more things, but at least most of the above should be > fixed > soon. Feel free to try out the devel version (otherwise it's pretty much > RC2, > no updates needed) and let me know what breaks/works/is still missing. > > Cheers, > > Markus > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > > |
From: Markus <ma...@ai...> - 2007-11-27 21:43:42
|
On Dienstag, 27. November 2007, Sergey Chernyshev wrote: > WOW! Markus, this is great present for being back from vacation! ;) I'll > test it on my instances as soon as I'll get some time with computer > tomorrow. Great, hope you like it. Surprisingly, most of the work had to go into=20 modifying Special:Ask to allow linking to queries using internal links, and= =20 into supporting the new separation of printout requests and queries (which= =20 also makes way for some more "presents"). I had to adopt the Special:ask=20 interface a little to account for this. I will drop another short note abou= t=20 recent changes and then be offline for a few days. I guess RC3 would be in= =20 order after this. Markus > > Sergey > > On Nov 23, 2007 4:01 PM, Markus Kr=F6tzsch <ma...@ai...> wr= ote: > > And another note: {{#ask}} is in SVN (in a first version). > > > > Working example query: > > > > {{#ask: [[Category:Country]] [[borders::Nigeria]] | > > ?population| > > ?area#km=B2 =3D ''Size''| > > format=3Dlist| > > limit =3D 3| > > link=3Dall| > > intro=3D<b>Test</b>_| > > }} > > > > Moreover, it is now of course possible to use templates and their params > > rather freely in {{#ask}}. Actually even some very unreasonable things > > work, > > but many cool things should also be possible. One real issue might be > > that uninitiated users might nest {{#ask}} in order to emulate > > <q>-subqueries, even though the latter are much more efficient and > > complete. Of course nesting sometimes is desirable: > > > > {{#ask: > > [[Category:Country]] > > [[population::>{{#ask:headers=3Dhide|?Population|[[Uganda]]}} ]] | > > sort=3Dpopulation| > > ?population > > }} > > > > This indeed works now. > > > > Here is what should hopefully work for #ask on SVN: > > > > * all printout formats other than "debug" (which still gives some HTML), > > * all known parameters (though some now are more flexible since you can > > use > > wiki-markup as values), > > * printout requests with the syntax "? property#unit =3D label", > > * basic queries, nested queries, value ranges, wildcards, and yet > > * <ask> should work as it did before (I hope). > > > > Here is what certainly does not work: > > > > * links to further results don't work in wikitext (we need another > > URL-scheme > > for that, but "external" links may be my first fix), > > * printouts of Categories do not work via "? Category" yet, > > * disjunctions in queries obviously do not work yet, since "|" is alrea= dy > > taken in templates (Sergey suggested a solution that would require > > queries to > > be the last #ask-parameter, but we may even get around this by providing > > an > > alternative syntax for "||"), > > * a query with limit 0 might show a broken further results link, > > * templated and embedded printers may pull annotations into the article > > where > > the query is -- this needs some advanced fix as there is currently no w= ay > > for > > us to distinguish #ask-printed results from the text someone entered > > directly. > > > > I guess there are more things, but at least most of the above should be > > fixed > > soon. Feel free to try out the devel version (otherwise it's pretty much > > RC2, > > no updates needed) and let me know what breaks/works/is still missing. > > > > Cheers, > > > > Markus > > > > -- > > Markus Kr=F6tzsch > > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > ma...@ai... www http://korrekt.org =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Sergey C. <sem...@an...> - 2007-11-27 23:04:51
|
Perfect - it works great for what I was planning to use it for! Now almost no barriers are there ;) Sergey On Nov 27, 2007 4:43 PM, Markus Kr=F6tzsch <ma...@ai...> wrot= e: > On Dienstag, 27. November 2007, Sergey Chernyshev wrote: > > WOW! Markus, this is great present for being back from vacation! ;) I'l= l > > test it on my instances as soon as I'll get some time with computer > > tomorrow. > > Great, hope you like it. Surprisingly, most of the work had to go into > modifying Special:Ask to allow linking to queries using internal links, > and > into supporting the new separation of printout requests and queries (whic= h > also makes way for some more "presents"). I had to adopt the Special:ask > interface a little to account for this. I will drop another short note > about > recent changes and then be offline for a few days. I guess RC3 would be i= n > order after this. > > Markus > > > > > > Sergey > > > > On Nov 23, 2007 4:01 PM, Markus Kr=F6tzsch <ma...@ai...> > wrote: > > > And another note: {{#ask}} is in SVN (in a first version). > > > > > > Working example query: > > > > > > {{#ask: [[Category:Country]] [[borders::Nigeria]] | > > > ?population| > > > ?area#km=B2 =3D ''Size''| > > > format=3Dlist| > > > limit =3D 3| > > > link=3Dall| > > > intro=3D<b>Test</b>_| > > > }} > > > > > > Moreover, it is now of course possible to use templates and their > params > > > rather freely in {{#ask}}. Actually even some very unreasonable thing= s > > > work, > > > but many cool things should also be possible. One real issue might be > > > that uninitiated users might nest {{#ask}} in order to emulate > > > <q>-subqueries, even though the latter are much more efficient and > > > complete. Of course nesting sometimes is desirable: > > > > > > {{#ask: > > > [[Category:Country]] > > > [[population::>{{#ask:headers=3Dhide|?Population|[[Uganda]]}} ]] | > > > sort=3Dpopulation| > > > ?population > > > }} > > > > > > This indeed works now. > > > > > > Here is what should hopefully work for #ask on SVN: > > > > > > * all printout formats other than "debug" (which still gives some > HTML), > > > * all known parameters (though some now are more flexible since you > can > > > use > > > wiki-markup as values), > > > * printout requests with the syntax "? property#unit =3D label", > > > * basic queries, nested queries, value ranges, wildcards, and yet > > > * <ask> should work as it did before (I hope). > > > > > > Here is what certainly does not work: > > > > > > * links to further results don't work in wikitext (we need another > > > URL-scheme > > > for that, but "external" links may be my first fix), > > > * printouts of Categories do not work via "? Category" yet, > > > * disjunctions in queries obviously do not work yet, since "|" is > already > > > taken in templates (Sergey suggested a solution that would require > > > queries to > > > be the last #ask-parameter, but we may even get around this by > providing > > > an > > > alternative syntax for "||"), > > > * a query with limit 0 might show a broken further results link, > > > * templated and embedded printers may pull annotations into the > article > > > where > > > the query is -- this needs some advanced fix as there is currently no > way > > > for > > > us to distinguish #ask-printed results from the text someone entered > > > directly. > > > > > > I guess there are more things, but at least most of the above should > be > > > fixed > > > soon. Feel free to try out the devel version (otherwise it's pretty > much > > > RC2, > > > no updates needed) and let me know what breaks/works/is still missing= . > > > > > > Cheers, > > > > > > Markus > > > > > > -- > > > Markus Kr=F6tzsch > > > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > > ma...@ai... www http://korrekt.org > > > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > |
From: Jim W. <wil...@gm...> - 2007-11-28 15:52:31
|
Of course, I am THRILLED that this is coming down the pipe. Sergey, If you're planning to do something crazy, I suggest checking out DPL and <shamelessplug>RegExParserFunctions</shamelessplug>. Combining {{#ask}} with {{#dpl}} and {{#regex}} can produce some very neat combinations. Also, I'm interested to see what you come up with in the way of {{#ask}} queries. -- Jim On Nov 27, 2007 5:04 PM, Sergey Chernyshev <sem...@an...> wrote: > Perfect - it works great for what I was planning to use it for! Now almos= t > no barriers are there ;) > > Sergey > > > > > On Nov 27, 2007 4:43 PM, Markus Kr=F6tzsch < ma...@ai...> w= rote: > > > > On Dienstag, 27. November 2007, Sergey Chernyshev wrote: > > > WOW! Markus, this is great present for being back from vacation! ;) I= 'll > > > test it on my instances as soon as I'll get some time with computer > > > tomorrow. > > > > Great, hope you like it. Surprisingly, most of the work had to go into > > modifying Special:Ask to allow linking to queries using internal links, > and > > into supporting the new separation of printout requests and queries (wh= ich > > also makes way for some more "presents"). I had to adopt the Special:as= k > > interface a little to account for this. I will drop another short note > about > > recent changes and then be offline for a few days. I guess RC3 would be= in > > order after this. > > > > Markus > > > > > > > > > > > > > > > > Sergey > > > > > > On Nov 23, 2007 4:01 PM, Markus Kr=F6tzsch <ma...@ai...= > > wrote: > > > > And another note: {{#ask}} is in SVN (in a first version). > > > > > > > > Working example query: > > > > > > > > {{#ask: [[Category:Country]] [[borders::Nigeria]] | > > > > ?population| > > > > ?area#km=B2 =3D ''Size''| > > > > format=3Dlist| > > > > limit =3D 3| > > > > link=3Dall| > > > > intro=3D<b>Test</b>_| > > > > }} > > > > > > > > Moreover, it is now of course possible to use templates and their > params > > > > rather freely in {{#ask}}. Actually even some very unreasonable thi= ngs > > > > work, > > > > but many cool things should also be possible. One real issue might = be > > > > that uninitiated users might nest {{#ask}} in order to emulate > > > > <q>-subqueries, even though the latter are much more efficient and > > > > complete. Of course nesting sometimes is desirable: > > > > > > > > {{#ask: > > > > [[Category:Country]] > > > > [[population::>{{#ask:headers=3Dhide|?Population|[[Uganda]]}} ]] | > > > > sort=3Dpopulation| > > > > ?population > > > > }} > > > > > > > > This indeed works now. > > > > > > > > Here is what should hopefully work for #ask on SVN: > > > > > > > > * all printout formats other than "debug" (which still gives some > HTML), > > > > * all known parameters (though some now are more flexible since you > can > > > > use > > > > wiki-markup as values), > > > > * printout requests with the syntax "? property#unit =3D label", > > > > * basic queries, nested queries, value ranges, wildcards, and yet > > > > * <ask> should work as it did before (I hope). > > > > > > > > Here is what certainly does not work: > > > > > > > > * links to further results don't work in wikitext (we need another > > > > URL-scheme > > > > for that, but "external" links may be my first fix), > > > > * printouts of Categories do not work via "? Category" yet, > > > > * disjunctions in queries obviously do not work yet, since "|" is > already > > > > taken in templates (Sergey suggested a solution that would require > > > > queries to > > > > be the last #ask-parameter, but we may even get around this by > providing > > > > an > > > > alternative syntax for "||"), > > > > * a query with limit 0 might show a broken further results link, > > > > * templated and embedded printers may pull annotations into the > article > > > > where > > > > the query is -- this needs some advanced fix as there is currently = no > way > > > > for > > > > us to distinguish #ask-printed results from the text someone entere= d > > > > directly. > > > > > > > > I guess there are more things, but at least most of the above shoul= d > be > > > > fixed > > > > soon. Feel free to try out the devel version (otherwise it's pretty > much > > > > RC2, > > > > no updates needed) and let me know what breaks/works/is still missi= ng. > > > > > > > > Cheers, > > > > > > > > Markus > > > > > > > > -- > > > > Markus Kr=F6tzsch > > > > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > > > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > > > ma...@ai... www http://korrekt.org > > > > > > > > -- > > > > > > > > Markus Kr=F6tzsch > > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > ma...@ai... www http://korrekt.org > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > |
From: Sergey C. <sem...@an...> - 2007-11-28 23:27:07
|
I use DPL for techpresentations.org but only because it has access to page meta-data (in my case page creation dates). I wasn't impressed with DPL's approach and prefer SMW approach which is about semantic data storage. Sergey On Nov 28, 2007 10:52 AM, Jim Wilson <wil...@gm...> wrote: > Of course, I am THRILLED that this is coming down the pipe. > > Sergey, If you're planning to do something crazy, I suggest checking > out DPL and <shamelessplug>RegExParserFunctions</shamelessplug>. > Combining {{#ask}} with {{#dpl}} and {{#regex}} can produce some very > neat combinations. Also, I'm interested to see what you come up with > in the way of {{#ask}} queries. > > -- Jim > > On Nov 27, 2007 5:04 PM, Sergey Chernyshev > <sem...@an...> wrote: > > Perfect - it works great for what I was planning to use it for! Now > almost > > no barriers are there ;) > > > > Sergey > > > > > > > > > > On Nov 27, 2007 4:43 PM, Markus Kr=F6tzsch < ma...@ai...> > wrote: > > > > > > On Dienstag, 27. November 2007, Sergey Chernyshev wrote: > > > > WOW! Markus, this is great present for being back from vacation! ;) > I'll > > > > test it on my instances as soon as I'll get some time with computer > > > > tomorrow. > > > > > > Great, hope you like it. Surprisingly, most of the work had to go int= o > > > modifying Special:Ask to allow linking to queries using internal > links, > > and > > > into supporting the new separation of printout requests and queries > (which > > > also makes way for some more "presents"). I had to adopt the > Special:ask > > > interface a little to account for this. I will drop another short not= e > > about > > > recent changes and then be offline for a few days. I guess RC3 would > be in > > > order after this. > > > > > > Markus > > > > > > > > > > > > > > > > > > > > > > > Sergey > > > > > > > > On Nov 23, 2007 4:01 PM, Markus Kr=F6tzsch <mak@aifb.uni-karlsruhe.= de> > > wrote: > > > > > And another note: {{#ask}} is in SVN (in a first version). > > > > > > > > > > Working example query: > > > > > > > > > > {{#ask: [[Category:Country]] [[borders::Nigeria]] | > > > > > ?population| > > > > > ?area#km=B2 =3D ''Size''| > > > > > format=3Dlist| > > > > > limit =3D 3| > > > > > link=3Dall| > > > > > intro=3D<b>Test</b>_| > > > > > }} > > > > > > > > > > Moreover, it is now of course possible to use templates and their > > params > > > > > rather freely in {{#ask}}. Actually even some very unreasonable > things > > > > > work, > > > > > but many cool things should also be possible. One real issue migh= t > be > > > > > that uninitiated users might nest {{#ask}} in order to emulate > > > > > <q>-subqueries, even though the latter are much more efficient an= d > > > > > complete. Of course nesting sometimes is desirable: > > > > > > > > > > {{#ask: > > > > > [[Category:Country]] > > > > > [[population::>{{#ask:headers=3Dhide|?Population|[[Uganda]]}} ]] = | > > > > > sort=3Dpopulation| > > > > > ?population > > > > > }} > > > > > > > > > > This indeed works now. > > > > > > > > > > Here is what should hopefully work for #ask on SVN: > > > > > > > > > > * all printout formats other than "debug" (which still gives some > > HTML), > > > > > * all known parameters (though some now are more flexible since > you > > can > > > > > use > > > > > wiki-markup as values), > > > > > * printout requests with the syntax "? property#unit =3D label", > > > > > * basic queries, nested queries, value ranges, wildcards, and yet > > > > > * <ask> should work as it did before (I hope). > > > > > > > > > > Here is what certainly does not work: > > > > > > > > > > * links to further results don't work in wikitext (we need anothe= r > > > > > URL-scheme > > > > > for that, but "external" links may be my first fix), > > > > > * printouts of Categories do not work via "? Category" yet, > > > > > * disjunctions in queries obviously do not work yet, since "|" is > > already > > > > > taken in templates (Sergey suggested a solution that would requir= e > > > > > queries to > > > > > be the last #ask-parameter, but we may even get around this by > > providing > > > > > an > > > > > alternative syntax for "||"), > > > > > * a query with limit 0 might show a broken further results link, > > > > > * templated and embedded printers may pull annotations into the > > article > > > > > where > > > > > the query is -- this needs some advanced fix as there is currentl= y > no > > way > > > > > for > > > > > us to distinguish #ask-printed results from the text someone > entered > > > > > directly. > > > > > > > > > > I guess there are more things, but at least most of the above > should > > be > > > > > fixed > > > > > soon. Feel free to try out the devel version (otherwise it's > pretty > > much > > > > > RC2, > > > > > no updates needed) and let me know what breaks/works/is still > missing. > > > > > > > > > > Cheers, > > > > > > > > > > Markus > > > > > > > > > > -- > > > > > Markus Kr=F6tzsch > > > > > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > > > > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > > > > ma...@ai... www http://korrekt.org > > > > > > > > > > > > -- > > > > > > > > > > > > Markus Kr=F6tzsch > > > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > > ma...@ai... www http://korrekt.org > > > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: The Future of Linux Business White Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future. > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > --=20 Sergey Chernyshev http://www.sergeychernyshev.com/ |
From: <dv...@ai...> - 2007-11-29 16:08:12
|
Any idea how to add page and wiki-meta data to SMW? The problem is, by simply adding further special properties (last modified date, creation date, etc.) it seems to clutter the property namespace... Well, doing the implementation is not trivial either, but heck :) Cheers, denny Sergey Chernyshev wrote: > I use DPL for techpresentations.org <http://techpresentations.org> but > only because it has access to page meta-data (in my case page creation > dates). I wasn't impressed with DPL's approach and prefer SMW approach > which is about semantic data storage. > > Sergey > > > On Nov 28, 2007 10:52 AM, Jim Wilson <wil...@gm... > <mailto:wil...@gm...>> wrote: > > Of course, I am THRILLED that this is coming down the pipe. > > Sergey, If you're planning to do something crazy, I suggest checking > out DPL and <shamelessplug>RegExParserFunctions</shamelessplug>. > Combining {{#ask}} with {{#dpl}} and {{#regex}} can produce some very > neat combinations. Also, I'm interested to see what you come up with > in the way of {{#ask}} queries. > > -- Jim > > On Nov 27, 2007 5:04 PM, Sergey Chernyshev > <sem...@an... > <mailto:sem...@an...>> wrote: > > Perfect - it works great for what I was planning to use it for! > Now almost > > no barriers are there ;) > > > > Sergey > > > > > > > > > > On Nov 27, 2007 4:43 PM, Markus Krötzsch < > ma...@ai... <mailto:ma...@ai...> > wrote: > > > > > > On Dienstag, 27. November 2007, Sergey Chernyshev wrote: > > > > WOW! Markus, this is great present for being back from > vacation! ;) I'll > > > > test it on my instances as soon as I'll get some time with > computer > > > > tomorrow. > > > > > > Great, hope you like it. Surprisingly, most of the work had to > go into > > > modifying Special:Ask to allow linking to queries using > internal links, > > and > > > into supporting the new separation of printout requests and > queries (which > > > also makes way for some more "presents"). I had to adopt the > Special:ask > > > interface a little to account for this. I will drop another > short note > > about > > > recent changes and then be offline for a few days. I guess RC3 > would be in > > > order after this. > > > > > > Markus > > > > > > > > > > > > > > > > > > > > > > > Sergey > > > > > > > > On Nov 23, 2007 4:01 PM, Markus Krötzsch > <ma...@ai... <mailto:ma...@ai...>> > > wrote: > > > > > And another note: {{#ask}} is in SVN (in a first version). > > > > > > > > > > Working example query: > > > > > > > > > > {{#ask: [[Category:Country]] [[borders::Nigeria]] | > > > > > ?population| > > > > > ?area#km² = ''Size''| > > > > > format=list| > > > > > limit = 3| > > > > > link=all| > > > > > intro=<b>Test</b>_| > > > > > }} > > > > > > > > > > Moreover, it is now of course possible to use templates and > their > > params > > > > > rather freely in {{#ask}}. Actually even some very > unreasonable things > > > > > work, > > > > > but many cool things should also be possible. One real > issue might be > > > > > that uninitiated users might nest {{#ask}} in order to emulate > > > > > <q>-subqueries, even though the latter are much more > efficient and > > > > > complete. Of course nesting sometimes is desirable: > > > > > > > > > > {{#ask: > > > > > [[Category:Country]] > > > > > [[population::>{{#ask:headers=hide|?Population|[[Uganda]]}} > ]] | > > > > > sort=population| > > > > > ?population > > > > > }} > > > > > > > > > > This indeed works now. > > > > > > > > > > Here is what should hopefully work for #ask on SVN: > > > > > > > > > > * all printout formats other than "debug" (which still > gives some > > HTML), > > > > > * all known parameters (though some now are more flexible > since you > > can > > > > > use > > > > > wiki-markup as values), > > > > > * printout requests with the syntax "? property#unit = label", > > > > > * basic queries, nested queries, value ranges, wildcards, > and yet > > > > > * <ask> should work as it did before (I hope). > > > > > > > > > > Here is what certainly does not work: > > > > > > > > > > * links to further results don't work in wikitext (we need > another > > > > > URL-scheme > > > > > for that, but "external" links may be my first fix), > > > > > * printouts of Categories do not work via "? Category" yet, > > > > > * disjunctions in queries obviously do not work yet, since > "|" is > > already > > > > > taken in templates (Sergey suggested a solution that would > require > > > > > queries to > > > > > be the last #ask-parameter, but we may even get around this by > > providing > > > > > an > > > > > alternative syntax for "||"), > > > > > * a query with limit 0 might show a broken further results > link, > > > > > * templated and embedded printers may pull annotations into > the > > article > > > > > where > > > > > the query is -- this needs some advanced fix as there is > currently no > > way > > > > > for > > > > > us to distinguish #ask-printed results from the text > someone entered > > > > > directly. > > > > > > > > > > I guess there are more things, but at least most of the > above should > > be > > > > > fixed > > > > > soon. Feel free to try out the devel version (otherwise > it's pretty > > much > > > > > RC2, > > > > > no updates needed) and let me know what breaks/works/is > still missing. > > > > > > > > > > Cheers, > > > > > > > > > > Markus > > > > > > > > > > -- > > > > > Markus Krötzsch > > > > > Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe > > > > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > > > > ma...@ai... > <mailto:ma...@ai...> www http://korrekt.org > > > > > > > > > > > > -- > > > > > > > > > > > > Markus Krötzsch > > > Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe > > > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > > ma...@ai... <mailto:ma...@ai...> > www http://korrekt.org > > > > > > > > > > ------------------------------------------------------------------------- > > > SF.Net email is sponsored by: The Future of Linux Business White > Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future. > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > <mailto:Sem...@li...> > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > <mailto:Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > -- > Sergey Chernyshev > http://www.sergeychernyshev.com/ <http://www.sergeychernyshev.com/> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Audra J. <au...@au...> - 2007-11-29 19:36:42
|
I don't think doing the implementation would really be that hard. =20 There would need to be a refreshMetaSemantics.php maintenance =20 script, and some hooks going into creating and saving pages and =20 maybe some other tasks like viewing. It should probably only keep =20 metadata on pages set to have evaluated annotations as defined in =20 $smwgNamespacesWithSemanticLinks. If implemented in the core, there =20 should be a global settings option so keeping this information can be =20= turned on or off. But I could just as easily see this as a SMW =20 extension, and it might be better that way. Either the special properties would need to be somewhat specific to =20 keep from clashing (page last modified on, page created on, page =20 edited by, number of page views, number of page edits), or users =20 should be allowed to specify what the property namespaces should be. =20 Users should also be allowed to customize what metadata gets saved, =20 because if they don't care about storing how many times a page is =20 viewed, they won't want the extra database hit to update that =20 semantic bit of data every time a page is viewed. I think have a pretty clear idea of how it could be done, =20 unfortunately I probably wouldn't be able to do an implementation =20 until late December. So if nobody else does one by then, feel free =20 hit me up and remind me, because it's actually something I kind of =20 want for myself. Lately I've been thinking of other possible =20 automatically added semantic data, too, like a user ratings system =20 extension that works with SMW. --Audra On Nov 29, 2007, at 8:08 AM, Denny Vrande=C4=8Di=C4=87 wrote: > Any idea how to add page and wiki-meta data to SMW? The problem is, by > simply adding further special properties (last modified date, creation > date, etc.) it seems to clutter the property namespace... Well, doing > the implementation is not trivial either, but heck :) > > Cheers, > denny > > > Sergey Chernyshev wrote: >> I use DPL for techpresentations.org <http://techpresentations.org> =20= >> but >> only because it has access to page meta-data (in my case page =20 >> creation >> dates). I wasn't impressed with DPL's approach and prefer SMW =20 >> approach >> which is about semantic data storage. >> >> Sergey >> >> >> On Nov 28, 2007 10:52 AM, Jim Wilson <wil...@gm... >> <mailto:wil...@gm...>> wrote: >> >> Of course, I am THRILLED that this is coming down the pipe. >> >> Sergey, If you're planning to do something crazy, I suggest =20 >> checking >> out DPL and <shamelessplug>RegExParserFunctions</shamelessplug>. >> Combining {{#ask}} with {{#dpl}} and {{#regex}} can produce =20 >> some very >> neat combinations. Also, I'm interested to see what you come =20 >> up with >> in the way of {{#ask}} queries. >> >> -- Jim >> >> On Nov 27, 2007 5:04 PM, Sergey Chernyshev >> <sem...@an... >> <mailto:sem...@an...>> wrote: >>> Perfect - it works great for what I was planning to use it for! >> Now almost >>> no barriers are there ;) >>> >>> Sergey >>> >>> >>> >>> >>> On Nov 27, 2007 4:43 PM, Markus Kr=C3=B6tzsch < >> ma...@ai... <mailto:ma...@ai...> > =20= >> wrote: >>>> >>>> On Dienstag, 27. November 2007, Sergey Chernyshev wrote: >>>>> WOW! Markus, this is great present for being back from >> vacation! ;) I'll >>>>> test it on my instances as soon as I'll get some time with >> computer >>>>> tomorrow. >>>> >>>> Great, hope you like it. Surprisingly, most of the work had to >> go into >>>> modifying Special:Ask to allow linking to queries using >> internal links, >>> and >>>> into supporting the new separation of printout requests and >> queries (which >>>> also makes way for some more "presents"). I had to adopt the >> Special:ask >>>> interface a little to account for this. I will drop another >> short note >>> about >>>> recent changes and then be offline for a few days. I guess RC3 >> would be in >>>> order after this. >>>> >>>> Markus >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Sergey >>>>> >>>>> On Nov 23, 2007 4:01 PM, Markus Kr=C3=B6tzsch >> <ma...@ai... <mailto:ma...@ai...>> >>> wrote: >>>>>> And another note: {{#ask}} is in SVN (in a first version). >>>>>> >>>>>> Working example query: >>>>>> >>>>>> {{#ask: [[Category:Country]] [[borders::Nigeria]] | >>>>>> ?population| >>>>>> ?area#km=C2=B2 =3D ''Size''| >>>>>> format=3Dlist| >>>>>> limit =3D 3| >>>>>> link=3Dall| >>>>>> intro=3D<b>Test</b>_| >>>>>> }} >>>>>> >>>>>> Moreover, it is now of course possible to use templates and >> their >>> params >>>>>> rather freely in {{#ask}}. Actually even some very >> unreasonable things >>>>>> work, >>>>>> but many cool things should also be possible. One real >> issue might be >>>>>> that uninitiated users might nest {{#ask}} in order to emulate >>>>>> <q>-subqueries, even though the latter are much more >> efficient and >>>>>> complete. Of course nesting sometimes is desirable: >>>>>> >>>>>> {{#ask: >>>>>> [[Category:Country]] >>>>>> [[population::>{{#ask:headers=3Dhide|?Population|[[Uganda]]}} >> ]] | >>>>>> sort=3Dpopulation| >>>>>> ?population >>>>>> }} >>>>>> >>>>>> This indeed works now. >>>>>> >>>>>> Here is what should hopefully work for #ask on SVN: >>>>>> >>>>>> * all printout formats other than "debug" (which still >> gives some >>> HTML), >>>>>> * all known parameters (though some now are more flexible >> since you >>> can >>>>>> use >>>>>> wiki-markup as values), >>>>>> * printout requests with the syntax "? property#unit =3D label", >>>>>> * basic queries, nested queries, value ranges, wildcards, >> and yet >>>>>> * <ask> should work as it did before (I hope). >>>>>> >>>>>> Here is what certainly does not work: >>>>>> >>>>>> * links to further results don't work in wikitext (we need >> another >>>>>> URL-scheme >>>>>> for that, but "external" links may be my first fix), >>>>>> * printouts of Categories do not work via "? Category" yet, >>>>>> * disjunctions in queries obviously do not work yet, since >> "|" is >>> already >>>>>> taken in templates (Sergey suggested a solution that would >> require >>>>>> queries to >>>>>> be the last #ask-parameter, but we may even get around this by >>> providing >>>>>> an >>>>>> alternative syntax for "||"), >>>>>> * a query with limit 0 might show a broken further results >> link, >>>>>> * templated and embedded printers may pull annotations into >> the >>> article >>>>>> where >>>>>> the query is -- this needs some advanced fix as there is >> currently no >>> way >>>>>> for >>>>>> us to distinguish #ask-printed results from the text >> someone entered >>>>>> directly. >>>>>> >>>>>> I guess there are more things, but at least most of the >> above should >>> be >>>>>> fixed >>>>>> soon. Feel free to try out the devel version (otherwise >> it's pretty >>> much >>>>>> RC2, >>>>>> no updates needed) and let me know what breaks/works/is >> still missing. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Markus >>>>>> >>>>>> -- >>>>>> Markus Kr=C3=B6tzsch >>>>>> Institut AIFB, Univers=C3=A4t Karlsruhe (TH), 76128 Karlsruhe >>>>>> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 >>>>>> ma...@ai... >> <mailto:ma...@ai...> www http://korrekt.org >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Markus Kr=C3=B6tzsch >>>> Institut AIFB, Univers=C3=A4t Karlsruhe (TH), 76128 Karlsruhe >>>> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 >>>> ma...@ai... <mailto:ma...@ai...> >> www http://korrekt.org >>>> >>> >>> >>> >> =20 >> ---------------------------------------------------------------------=20= >> ---- >> >>> SF.Net email is sponsored by: The Future of Linux Business White >> Paper >>> from Novell. =46rom the desktop to the data center, Linux is going >>> mainstream. Let it simplify your IT future. >>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>> _______________________________________________ >>> Semediawiki-devel mailing list >>> Sem...@li... >> <mailto:Sem...@li...> >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>> >>> >> >> =20 >> ---------------------------------------------------------------------=20= >> ---- >> SF.Net email is sponsored by: The Future of Linux Business =20 >> White Paper >> from Novell. =46rom the desktop to the data center, Linux is = going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> <mailto:Sem...@li...> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> >> >> >> --=20 >> Sergey Chernyshev >> http://www.sergeychernyshev.com/ <http://www.sergeychernyshev.com/> >> >> >> ---------------------------------------------------------------------=20= >> --- >> >> ---------------------------------------------------------------------=20= >> ---- >> SF.Net email is sponsored by: The Future of Linux Business White =20 >> Paper >> from Novell. =46rom the desktop to the data center, Linux is going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> >> >> ---------------------------------------------------------------------=20= >> --- >> >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > ----------------------------------------------------------------------=20= > --- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. =46rom the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: S P. <in...@sk...> - 2007-11-29 22:10:13
|
Denny Vrandečić wrote: > Any idea how to add page and wiki-meta data to SMW? The problem is, by > simply adding further special properties (last modified date, creation > date, etc.) it seems to clutter the property namespace... Well, doing > the implementation is not trivial either, but heck :) Perhaps a special virtual namespace, e.g. [[ArticleMetaProperty:Last modified date]] ? The SMW query code would notice this virtual namespace and retrieve the metadata. For extensibility, it could call back into custom code that gets a particular metadatum property; though appending extra SQL code seems very fragile. And doing this really ties SMW into MediaWiki database internals. Some of the names you want to query on are in http://meta.wikimedia.org/wiki/Help:Variable, like {{REVISIONTIMESTAMP}}. But this missing things like "username who last modified", "page size", etc. Hard to do, hard to maintain, hard to extend, but it would be very useful. -- =S |
From: cnit <cn...@un...> - 2007-12-03 14:08:26
|
> And another note: {{#ask}} is in SVN (in a first version). Thank you! > Working example query: > {{#ask: [[Category:Country]] [[borders::Nigeria]] | > ?population| > ?area#km² = ''Size''| > format=list| > limit = 3| > link=all| > intro=<b>Test</b>_| > }} It seems that the category specific syntax is identical to ask tag, parameters of the output are specified without leading questions, starting with leading question defines the searching property, if I got it right.. I've tried to convert my SMW 0.7 (really working) query to SMW 1.0RC3 #ask query. But I've stumbled with the problem. There's the query I use, only the cyrillic property names and format strings are translated (because it may be confusing to read Cyrillic to westerners, if there's a need to get original bytecodes, I can send them with escaped strings): ---- {{#ask: [[Category:News]] | ?Date| sort=Date| order=descending| limit=3| format=template| template=newsrow| default=There was no news| searchlabel=Browse all news...| }} ---- The results set is correct list of links to the pages where the property "Date" is defined, {{{1}}} and {{{2}}} parameter are correctly expanded in the template, but.. there's no sorting! The results were sorted by Date field in SMW 0.7, now they aren't. I've tried to figure out what's wrong, it must be either something had changed with syntax of the query, or the query is incorrectly parsed. After browsing through few nested function calls, I've found method getQueryResult(SMWQuery $query) in SMW_SQLStore.php, where's the following code: ---- if ( $smwgQSortingSupport ) { $order = $query->ascending ? 'ASC' : 'DESC'; if ( ($this->m_sortfield == false) && ($this->m_sortkey == false) ) { $sql_options['ORDER BY'] = "$pagetable.page_title $order "; // default } elseif ($this->m_sortfield != false) { $sql_options['ORDER BY'] = $this->m_sortfield . " $order "; } // else: sortkey given but not found: do not sort } ---- My $smwgQSortingSupport is true, of course. But the content of $this is such: ---- object(SMWSQLStore)#140 (3) { ["m_sortkey:protected"]=> string(8) "\u0414\u0430\u0442\u0430" ["m_sortfield:protected"]=> bool(false) ["m_usedtables:protected"]=> array(1) { [0]=> string(5) "cats1" } } ---- translated version: object(SMWSQLStore)#140 (3) { ["m_sortkey:protected"]=> string(8) "Date" ["m_sortfield:protected"]=> bool(false) ["m_usedtables:protected"]=> array(1) { [0]=> string(5) "cats1" } } ---- You see, that my m_sortkey is proper (Date) - it's not false, but for some strange reason my m_sortfield is false :-( The following code in createSQLQuery seems to be designated for subqueries and not being executed in my case: ---- if ($sub) { $nexttables = array(); $nexttables['p' . $tablename] = $table; // keep only current table for reference $this->createSQLQuery($description->getDescription(), $from, $subwhere, $db, $nexttables, $nary_pos); if ($sort) { $this->m_sortfield = "$table.$sort"; } if ( $subwhere != '') { $where .= ' AND (' . $subwhere . ')'; } } ---- So, the sql_options ORDER BY is not set.. After that, I've changed the "format" parameter value to "debug", ---- ---- here's the SQL query it tries to execute: ---- Generated Wiki-Query <q> <q>+ || \u0418\u0437\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0438\u0435:+</q> </q> Query-Size: 3 Query-Depth: 0 SQL-Query SELECT DISTINCT `page`.page_title as title, `page`.page_namespace as namespace FROM `cats3`, `page` INNER JOIN `categorylinks` AS cl2 ON cl2.cl_from=`page`.page_id WHERE ((`page`.page_namespace='0') OR (`page`.page_namespace='6')) AND (cats3.title=cl2.cl_to) SQL-Query options LIMIT=4 OFFSET=0 Errors and Warnings Auxilliary tables used cats3: \u041d\u043e\u0432\u043e\u0441\u0442\u0438, ---- translated version: Generated Wiki-Query <q> <q>+ || Image:+</q> </q> Query-Size: 3 Query-Depth: 0 SQL-Query SELECT DISTINCT `page`.page_title as title, `page`.page_namespace as namespace FROM `cats3`, `page` INNER JOIN `categorylinks` AS cl2 ON cl2.cl_from=`page`.page_id WHERE ((`page`.page_namespace='0') OR (`page`.page_namespace='6')) AND (cats3.title=cl2.cl_to) SQL-Query options LIMIT=4 OFFSET=0 Errors and Warnings Auxilliary tables used cats3: News, ---- If you need any additional information to debug, I can provide. The Property:Date is defined as "[[has type::Type:Date]]" of course. I don't know whether it's my simple mistake with query, or a some kind of bug in SMW.. Dmitriy |