From: Jörg H. <hei...@on...> - 2009-04-01 08:25:26
|
Hi, I am working on our query front-end for inline ask queries which, in the next version, immediately shows your result set while you are creating your query. In order to (dynamically) support all available result printers and to not hardcode all this stuff which might change in the future I found the array holding name and class of each available result printer ($smwgResultFormats). That's pretty cool but I cannot get additional meta information for each printer. I doubt that users understand that "ul" stands for "unordered list" so I would love to have a short description (maybe also a longer one) method for each result printer. Also, some printers support additional parameters which are necessary for the frontend to know about. Here, a second method would be nice to have in order to not hard-code this information. What do you think about these additions? cheers, Jörg |
From: Yaron K. <ya...@gm...> - 2009-04-01 16:44:32
|
I think a way for formats to publish both a description of themselves and the set of parameters they take would be very helpful: it could be that the easiest way to do it is just to expand the information that $smwgResultFormats holds, although maybe the better solution is, as you suggest, to add methods like getDescription() and getAllowedParams() to the SMWResultPrinter class, and allow any format class to override these methods. -Yaron On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann <hei...@on...> wrote: > Hi, > > I am working on our query front-end for inline ask queries which, in the > next version, immediately shows your result set while you are creating > your query. > In order to (dynamically) support all available result printers and to > not hardcode all this stuff which might change in the future I found the > array holding name and class of each available result printer > ($smwgResultFormats). That's pretty cool but I cannot get additional > meta information for each printer. > > I doubt that users understand that "ul" stands for "unordered list" so I > would love to have a short description (maybe also a longer one) method > for each result printer. > Also, some printers support additional parameters which are necessary > for the frontend to know about. Here, a second method would be nice to > have in order to not hard-code this information. > > What do you think about these additions? > > cheers, > Jörg > > > ------------------------------------------------------------------------------ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Markus K. <ma...@se...> - 2009-04-02 07:50:04
|
On Mittwoch, 1. April 2009, Yaron Koren wrote: > I think a way for formats to publish both a description of themselves and > the set of parameters they take would be very helpful: it could be that the > easiest way to do it is just to expand the information that > $smwgResultFormats holds, although maybe the better solution is, as you > suggest, to add methods like getDescription() and getAllowedParams() to the > SMWResultPrinter class, and allow any format class to override these > methods. I also agree with Jörg's observation. I strongly favour Yaron's second proposal: extending the printer class instead of extending the static array. A related solution has been in my mind for some time, but I did not find time to implement it yet: * In order to keep the information that is available for each result printer flexible and extendible, it would be best if the printer objects would implement access methods for this information. Two main advantages are: (1) The meta information is kept with the code of the printer class, so printer format extensions like SRF are still easy to implement in one file. (2) The abstract result printer parent class can always implement fallback methods, so that non-core printers are compatible to new SMW versions even if they do not support this meta-data yet. * The task then boils down to getting a printer object for a given printer identifier (like "ul"). In order to be perfectly compatible with SMW, this should be done by calling SMWQueryProcessor::getResultPrinter(). The problem is that this function currently requires further parameters: especially it depends on the query result. This is not really needed and can be avoided with some extra coding from my side. * What remains to discuss is what meta information it is that each printer should provide. A human readable name would be a good start, I guess. Another useful feature might be a function that returns the list of supported additional parameters with a short "signature" to indicate their input type (How should this look? How do you get labels/descriptions for these parameters?). Anything else? I think I can provide the implementation over the weekend then. -- Markus > > -Yaron > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann <hei...@on...> wrote: > > Hi, > > > > I am working on our query front-end for inline ask queries which, in the > > next version, immediately shows your result set while you are creating > > your query. > > In order to (dynamically) support all available result printers and to > > not hardcode all this stuff which might change in the future I found the > > array holding name and class of each available result printer > > ($smwgResultFormats). That's pretty cool but I cannot get additional > > meta information for each printer. > > > > I doubt that users understand that "ul" stands for "unordered list" so I > > would love to have a short description (maybe also a longer one) method > > for each result printer. > > Also, some printers support additional parameters which are necessary > > for the frontend to know about. Here, a second method would be nice to > > have in order to not hard-code this information. > > > > What do you think about these additions? > > > > cheers, > > Jörg > > > > > > ------------------------------------------------------------------------- > >----- _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org ma...@se... |
From: Markus K. <ma...@se...> - 2009-04-05 16:25:07
|
As promised, SMW has now been updated to support some of the requested functionalities: * To get the list of all available formats, access $smwgResultFormats. * To get a result printer object, use SMWQueryProcessor::getResultPrinter(). * To get the name of a printer object, use $printer->getName(). The new functions are documented in the code (or see the API docs). The format selector for Special:Ask has been improved to use these features. Note that not all SRF formats provide localised names yet; examples on how to add translations are found in all SMW result printers and in some of the SRF printers. There was also another change: printers that only show download links when used inline can indicate to SMW that no query needs to be executed in this case. To do this, simply implement the method getQueryMode() as e.g. in SMW_QP_CSV.php. If you do not do this, SMW will always compute all query results, even if the printer ignores them anyway. Besides Name and QueryMode, no further meta-data has been added. Especially, I do not know yet how to provide information about available parameters. There is a list of parameter identifiers, but what else should be there for each of them: localised labels, expected type of input, anything else? Also, I was unsure whether longer descriptions besides the names should be available for printers -- doing this feels like moving the user handbook to the message file. Cheers, Markus On Donnerstag, 2. April 2009, Markus Krötzsch wrote: > On Mittwoch, 1. April 2009, Yaron Koren wrote: > > I think a way for formats to publish both a description of themselves and > > the set of parameters they take would be very helpful: it could be that > > the easiest way to do it is just to expand the information that > > $smwgResultFormats holds, although maybe the better solution is, as you > > suggest, to add methods like getDescription() and getAllowedParams() to > > the SMWResultPrinter class, and allow any format class to override these > > methods. > > I also agree with Jörg's observation. I strongly favour Yaron's second > proposal: extending the printer class instead of extending the static > array. A related solution has been in my mind for some time, but I did not > find time to implement it yet: > > * In order to keep the information that is available for each result > printer flexible and extendible, it would be best if the printer objects > would implement access methods for this information. Two main advantages > are: > > (1) The meta information is kept with the code of the printer class, so > printer format extensions like SRF are still easy to implement in one file. > > (2) The abstract result printer parent class can always implement fallback > methods, so that non-core printers are compatible to new SMW versions even > if they do not support this meta-data yet. > > * The task then boils down to getting a printer object for a given printer > identifier (like "ul"). In order to be perfectly compatible with SMW, this > should be done by calling SMWQueryProcessor::getResultPrinter(). The > problem is that this function currently requires further parameters: > especially it depends on the query result. This is not really needed and > can be avoided with some extra coding from my side. > > * What remains to discuss is what meta information it is that each printer > should provide. A human readable name would be a good start, I guess. > Another useful feature might be a function that returns the list of > supported additional parameters with a short "signature" to indicate their > input type (How should this look? How do you get labels/descriptions for > these parameters?). Anything else? > > I think I can provide the implementation over the weekend then. > > -- Markus > > > -Yaron > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann <hei...@on...> wrote: > > > Hi, > > > > > > I am working on our query front-end for inline ask queries which, in > > > the next version, immediately shows your result set while you are > > > creating your query. > > > In order to (dynamically) support all available result printers and to > > > not hardcode all this stuff which might change in the future I found > > > the array holding name and class of each available result printer > > > ($smwgResultFormats). That's pretty cool but I cannot get additional > > > meta information for each printer. > > > > > > I doubt that users understand that "ul" stands for "unordered list" so > > > I would love to have a short description (maybe also a longer one) > > > method for each result printer. > > > Also, some printers support additional parameters which are necessary > > > for the frontend to know about. Here, a second method would be nice to > > > have in order to not hard-code this information. > > > > > > What do you think about these additions? > > > > > > cheers, > > > Jörg > > > > > > > > > ----------------------------------------------------------------------- > > >-- ----- _______________________________________________ > > > Semediawiki-devel mailing list > > > Sem...@li... > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org ma...@se... |
From: Yaron K. <ya...@gm...> - 2009-04-06 00:09:45
|
Hi, This is great - the self-description/"reflection" feature will be allow for a big improvement to Special:Ask (and evidently Halo as well). This, in addition to Sergey's previous changes, turns Special:Ask from somewhat of a hacker interface to an easy-to-use entry point for those getting started with Semantic MediaWiki and inline queries. Actually, the more I think about it, the more I think this is a big step forward in turning SMW into a real consumer application, since it will mean that people can run (and administrators can save) queries on the data without needing to read through a lot of documentation. To that end, I would say that yes, there should be descriptive labels for each printer, retrieved from message files - just as there should be labels for each parameter. Having good inline help is very common among mature software applications - it's considerably easier to use than a user handbook. Obviously, it becomes an issue if someone wants to put whole paragraphs or even pages into the application, but a simple one-sentence description of each concept is, I think, completely reasonable. And I should note another veery important reason to put such information into the application - to enable translation; which should make creating inline queries quite a bit easier for those who can't speak English. Finally, if you're at all considering adding more meta-data to each printer, let me suggest another field: a "default limit" value, which would override the wiki's value for $smwgQDefaultLimit (though not a "limit=" parameter set in the query). This would allow the "math" formats in SRF (sum, average, min, max) to considerably raise the number of values passed in to them by default, since all of them, especially 'sum', require all values to be passed in to produce a meaningful result. It would similarly be helpful for 'calendar'. A default limit value could also be helpful for the export formats (csv, json, icalendar, rss), although for them there's already a workaround because they create, essentially, a link to themselves, with that link setting the correct limit. -Yaron On Sun, Apr 5, 2009 at 12:24 PM, Markus Krötzsch < ma...@se...> wrote: > As promised, SMW has now been updated to support some of the requested > functionalities: > > * To get the list of all available formats, access $smwgResultFormats. > * To get a result printer object, use > SMWQueryProcessor::getResultPrinter(). > * To get the name of a printer object, use $printer->getName(). > > The new functions are documented in the code (or see the API docs). > > The format selector for Special:Ask has been improved to use these > features. > Note that not all SRF formats provide localised names yet; examples on how > to > add translations are found in all SMW result printers and in some of the > SRF > printers. > > There was also another change: printers that only show download links when > used inline can indicate to SMW that no query needs to be executed in this > case. To do this, simply implement the method getQueryMode() as e.g. in > SMW_QP_CSV.php. If you do not do this, SMW will always compute all query > results, even if the printer ignores them anyway. > > Besides Name and QueryMode, no further meta-data has been added. > Especially, I > do not know yet how to provide information about available parameters. > There > is a list of parameter identifiers, but what else should be there for each > of > them: localised labels, expected type of input, anything else? Also, I was > unsure whether longer descriptions besides the names should be available > for > printers -- doing this feels like moving the user handbook to the message > file. > > Cheers, > > Markus > > On Donnerstag, 2. April 2009, Markus Krötzsch wrote: > > On Mittwoch, 1. April 2009, Yaron Koren wrote: > > > I think a way for formats to publish both a description of themselves > and > > > the set of parameters they take would be very helpful: it could be that > > > the easiest way to do it is just to expand the information that > > > $smwgResultFormats holds, although maybe the better solution is, as you > > > suggest, to add methods like getDescription() and getAllowedParams() to > > > the SMWResultPrinter class, and allow any format class to override > these > > > methods. > > > > I also agree with Jörg's observation. I strongly favour Yaron's second > > proposal: extending the printer class instead of extending the static > > array. A related solution has been in my mind for some time, but I did > not > > find time to implement it yet: > > > > * In order to keep the information that is available for each result > > printer flexible and extendible, it would be best if the printer objects > > would implement access methods for this information. Two main advantages > > are: > > > > (1) The meta information is kept with the code of the printer class, so > > printer format extensions like SRF are still easy to implement in one > file. > > > > (2) The abstract result printer parent class can always implement > fallback > > methods, so that non-core printers are compatible to new SMW versions > even > > if they do not support this meta-data yet. > > > > * The task then boils down to getting a printer object for a given > printer > > identifier (like "ul"). In order to be perfectly compatible with SMW, > this > > should be done by calling SMWQueryProcessor::getResultPrinter(). The > > problem is that this function currently requires further parameters: > > especially it depends on the query result. This is not really needed and > > can be avoided with some extra coding from my side. > > > > * What remains to discuss is what meta information it is that each > printer > > should provide. A human readable name would be a good start, I guess. > > Another useful feature might be a function that returns the list of > > supported additional parameters with a short "signature" to indicate > their > > input type (How should this look? How do you get labels/descriptions for > > these parameters?). Anything else? > > > > I think I can provide the implementation over the weekend then. > > > > -- Markus > > > > > -Yaron > > > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann <hei...@on...> > wrote: > > > > Hi, > > > > > > > > I am working on our query front-end for inline ask queries which, in > > > > the next version, immediately shows your result set while you are > > > > creating your query. > > > > In order to (dynamically) support all available result printers and > to > > > > not hardcode all this stuff which might change in the future I found > > > > the array holding name and class of each available result printer > > > > ($smwgResultFormats). That's pretty cool but I cannot get additional > > > > meta information for each printer. > > > > > > > > I doubt that users understand that "ul" stands for "unordered list" > so > > > > I would love to have a short description (maybe also a longer one) > > > > method for each result printer. > > > > Also, some printers support additional parameters which are necessary > > > > for the frontend to know about. Here, a second method would be nice > to > > > > have in order to not hard-code this information. > > > > > > > > What do you think about these additions? > > > > > > > > cheers, > > > > Jörg > > > > > > > > > > > > > ----------------------------------------------------------------------- > > > >-- ----- _______________________________________________ > > > > Semediawiki-devel mailing list > > > > Sem...@li... > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > -- > Markus Krötzsch > Semantic MediaWiki http://semantic-mediawiki.org > http://korrekt.org ma...@se... > > |
From: Markus K. <ma...@se...> - 2009-04-06 14:01:25
|
I am convinced :-). What remains unclear to me is how to report the expected input type of a parameter to a UI-creating interface. The types are not really standard things like "integer" and "string" but also things like "some template name" or "the name of a property printout in the query". Should we introduce yet another system of type constants? -- Markus On Montag, 6. April 2009, Yaron Koren wrote: > Hi, > > This is great - the self-description/"reflection" feature will be allow for > a big improvement to Special:Ask (and evidently Halo as well). This, in > addition to Sergey's previous changes, turns Special:Ask from somewhat of a > hacker interface to an easy-to-use entry point for those getting started > with Semantic MediaWiki and inline queries. Actually, the more I think > about it, the more I think this is a big step forward in turning SMW into a > real consumer application, since it will mean that people can run (and > administrators can save) queries on the data without needing to read > through a lot of documentation. > > To that end, I would say that yes, there should be descriptive labels for > each printer, retrieved from message files - just as there should be labels > for each parameter. Having good inline help is very common among mature > software applications - it's considerably easier to use than a user > handbook. Obviously, it becomes an issue if someone wants to put whole > paragraphs or even pages into the application, but a simple one-sentence > description of each concept is, I think, completely reasonable. And I > should note another veery important reason to put such information into the > application - to enable translation; which should make creating inline > queries quite a bit easier for those who can't speak English. > > Finally, if you're at all considering adding more meta-data to each > printer, let me suggest another field: a "default limit" value, which would > override the wiki's value for $smwgQDefaultLimit (though not a "limit=" > parameter set in the query). This would allow the "math" formats in SRF > (sum, average, min, max) to considerably raise the number of values passed > in to them by default, since all of them, especially 'sum', require all > values to be passed in to produce a meaningful result. It would similarly > be helpful for 'calendar'. A default limit value could also be helpful for > the export formats (csv, json, icalendar, rss), although for them there's > already a workaround because they create, essentially, a link to > themselves, with that link setting the correct limit. > > -Yaron > > > On Sun, Apr 5, 2009 at 12:24 PM, Markus Krötzsch < > > ma...@se...> wrote: > > As promised, SMW has now been updated to support some of the requested > > functionalities: > > > > * To get the list of all available formats, access $smwgResultFormats. > > * To get a result printer object, use > > SMWQueryProcessor::getResultPrinter(). > > * To get the name of a printer object, use $printer->getName(). > > > > The new functions are documented in the code (or see the API docs). > > > > The format selector for Special:Ask has been improved to use these > > features. > > Note that not all SRF formats provide localised names yet; examples on > > how to > > add translations are found in all SMW result printers and in some of the > > SRF > > printers. > > > > There was also another change: printers that only show download links > > when used inline can indicate to SMW that no query needs to be executed > > in this case. To do this, simply implement the method getQueryMode() as > > e.g. in SMW_QP_CSV.php. If you do not do this, SMW will always compute > > all query results, even if the printer ignores them anyway. > > > > Besides Name and QueryMode, no further meta-data has been added. > > Especially, I > > do not know yet how to provide information about available parameters. > > There > > is a list of parameter identifiers, but what else should be there for > > each of > > them: localised labels, expected type of input, anything else? Also, I > > was unsure whether longer descriptions besides the names should be > > available for > > printers -- doing this feels like moving the user handbook to the message > > file. > > > > Cheers, > > > > Markus > > > > On Donnerstag, 2. April 2009, Markus Krötzsch wrote: > > > On Mittwoch, 1. April 2009, Yaron Koren wrote: > > > > I think a way for formats to publish both a description of themselves > > > > and > > > > > > the set of parameters they take would be very helpful: it could be > > > > that the easiest way to do it is just to expand the information that > > > > $smwgResultFormats holds, although maybe the better solution is, as > > > > you suggest, to add methods like getDescription() and > > > > getAllowedParams() to the SMWResultPrinter class, and allow any > > > > format class to override > > > > these > > > > > > methods. > > > > > > I also agree with Jörg's observation. I strongly favour Yaron's second > > > proposal: extending the printer class instead of extending the static > > > array. A related solution has been in my mind for some time, but I did > > > > not > > > > > find time to implement it yet: > > > > > > * In order to keep the information that is available for each result > > > printer flexible and extendible, it would be best if the printer > > > objects would implement access methods for this information. Two main > > > advantages are: > > > > > > (1) The meta information is kept with the code of the printer class, so > > > printer format extensions like SRF are still easy to implement in one > > > > file. > > > > > (2) The abstract result printer parent class can always implement > > > > fallback > > > > > methods, so that non-core printers are compatible to new SMW versions > > > > even > > > > > if they do not support this meta-data yet. > > > > > > * The task then boils down to getting a printer object for a given > > > > printer > > > > > identifier (like "ul"). In order to be perfectly compatible with SMW, > > > > this > > > > > should be done by calling SMWQueryProcessor::getResultPrinter(). The > > > problem is that this function currently requires further parameters: > > > especially it depends on the query result. This is not really needed > > > and can be avoided with some extra coding from my side. > > > > > > * What remains to discuss is what meta information it is that each > > > > printer > > > > > should provide. A human readable name would be a good start, I guess. > > > Another useful feature might be a function that returns the list of > > > supported additional parameters with a short "signature" to indicate > > > > their > > > > > input type (How should this look? How do you get labels/descriptions > > > for these parameters?). Anything else? > > > > > > I think I can provide the implementation over the weekend then. > > > > > > -- Markus > > > > > > > -Yaron > > > > > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann <hei...@on...> > > > > wrote: > > > > > Hi, > > > > > > > > > > I am working on our query front-end for inline ask queries which, > > > > > in the next version, immediately shows your result set while you > > > > > are creating your query. > > > > > In order to (dynamically) support all available result printers and > > > > to > > > > > > > not hardcode all this stuff which might change in the future I > > > > > found the array holding name and class of each available result > > > > > printer ($smwgResultFormats). That's pretty cool but I cannot get > > > > > additional meta information for each printer. > > > > > > > > > > I doubt that users understand that "ul" stands for "unordered list" > > > > so > > > > > > > I would love to have a short description (maybe also a longer one) > > > > > method for each result printer. > > > > > Also, some printers support additional parameters which are > > > > > necessary for the frontend to know about. Here, a second method > > > > > would be nice > > > > to > > > > > > > have in order to not hard-code this information. > > > > > > > > > > What do you think about these additions? > > > > > > > > > > cheers, > > > > > Jörg > > > > ----------------------------------------------------------------------- > > > > > > >-- ----- _______________________________________________ > > > > > Semediawiki-devel mailing list > > > > > Sem...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > > Markus Krötzsch > > Semantic MediaWiki http://semantic-mediawiki.org > > http://korrekt.org ma...@se... -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org ma...@se... |
From: Sergey C. <ser...@gm...> - 2009-04-06 14:57:51
|
Hey, I'm back from San Francisco and what I find? the Special:Ask discussion is getting hot ;) I have a few things to input - my experience shows that building universal UI builder is a hard thing to do - Yaron can probably second that. My approach to this problem before was to have subclasses build their own forms and parse their own parameters, similar to how extending MW preferences interface is done. This is a way to avoid new constants and constraints on input UI parameters for specific query printers, more over, since all of this functionality is implemented in PHP and not reading user-generated content within the pages, I think it makes the most sense to just leave it to subclassing approach which will allow more flexibility for SRF implementors. Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Mon, Apr 6, 2009 at 10:01 AM, Markus Krötzsch < ma...@se...> wrote: > I am convinced :-). What remains unclear to me is how to report the > expected > input type of a parameter to a UI-creating interface. The types are not > really > standard things like "integer" and "string" but also things like "some > template name" or "the name of a property printout in the query". Should we > introduce yet another system of type constants? > > -- Markus > > On Montag, 6. April 2009, Yaron Koren wrote: > > Hi, > > > > This is great - the self-description/"reflection" feature will be allow > for > > a big improvement to Special:Ask (and evidently Halo as well). This, in > > addition to Sergey's previous changes, turns Special:Ask from somewhat of > a > > hacker interface to an easy-to-use entry point for those getting started > > with Semantic MediaWiki and inline queries. Actually, the more I think > > about it, the more I think this is a big step forward in turning SMW into > a > > real consumer application, since it will mean that people can run (and > > administrators can save) queries on the data without needing to read > > through a lot of documentation. > > > > To that end, I would say that yes, there should be descriptive labels for > > each printer, retrieved from message files - just as there should be > labels > > for each parameter. Having good inline help is very common among mature > > software applications - it's considerably easier to use than a user > > handbook. Obviously, it becomes an issue if someone wants to put whole > > paragraphs or even pages into the application, but a simple one-sentence > > description of each concept is, I think, completely reasonable. And I > > should note another veery important reason to put such information into > the > > application - to enable translation; which should make creating inline > > queries quite a bit easier for those who can't speak English. > > > > Finally, if you're at all considering adding more meta-data to each > > printer, let me suggest another field: a "default limit" value, which > would > > override the wiki's value for $smwgQDefaultLimit (though not a "limit=" > > parameter set in the query). This would allow the "math" formats in SRF > > (sum, average, min, max) to considerably raise the number of values > passed > > in to them by default, since all of them, especially 'sum', require all > > values to be passed in to produce a meaningful result. It would similarly > > be helpful for 'calendar'. A default limit value could also be helpful > for > > the export formats (csv, json, icalendar, rss), although for them there's > > already a workaround because they create, essentially, a link to > > themselves, with that link setting the correct limit. > > > > -Yaron > > > > > > On Sun, Apr 5, 2009 at 12:24 PM, Markus Krötzsch < > > > > ma...@se...> wrote: > > > As promised, SMW has now been updated to support some of the requested > > > functionalities: > > > > > > * To get the list of all available formats, access $smwgResultFormats. > > > * To get a result printer object, use > > > SMWQueryProcessor::getResultPrinter(). > > > * To get the name of a printer object, use $printer->getName(). > > > > > > The new functions are documented in the code (or see the API docs). > > > > > > The format selector for Special:Ask has been improved to use these > > > features. > > > Note that not all SRF formats provide localised names yet; examples on > > > how to > > > add translations are found in all SMW result printers and in some of > the > > > SRF > > > printers. > > > > > > There was also another change: printers that only show download links > > > when used inline can indicate to SMW that no query needs to be executed > > > in this case. To do this, simply implement the method getQueryMode() as > > > e.g. in SMW_QP_CSV.php. If you do not do this, SMW will always compute > > > all query results, even if the printer ignores them anyway. > > > > > > Besides Name and QueryMode, no further meta-data has been added. > > > Especially, I > > > do not know yet how to provide information about available parameters. > > > There > > > is a list of parameter identifiers, but what else should be there for > > > each of > > > them: localised labels, expected type of input, anything else? Also, I > > > was unsure whether longer descriptions besides the names should be > > > available for > > > printers -- doing this feels like moving the user handbook to the > message > > > file. > > > > > > Cheers, > > > > > > Markus > > > > > > On Donnerstag, 2. April 2009, Markus Krötzsch wrote: > > > > On Mittwoch, 1. April 2009, Yaron Koren wrote: > > > > > I think a way for formats to publish both a description of > themselves > > > > > > and > > > > > > > > the set of parameters they take would be very helpful: it could be > > > > > that the easiest way to do it is just to expand the information > that > > > > > $smwgResultFormats holds, although maybe the better solution is, as > > > > > you suggest, to add methods like getDescription() and > > > > > getAllowedParams() to the SMWResultPrinter class, and allow any > > > > > format class to override > > > > > > these > > > > > > > > methods. > > > > > > > > I also agree with Jörg's observation. I strongly favour Yaron's > second > > > > proposal: extending the printer class instead of extending the static > > > > array. A related solution has been in my mind for some time, but I > did > > > > > > not > > > > > > > find time to implement it yet: > > > > > > > > * In order to keep the information that is available for each result > > > > printer flexible and extendible, it would be best if the printer > > > > objects would implement access methods for this information. Two main > > > > advantages are: > > > > > > > > (1) The meta information is kept with the code of the printer class, > so > > > > printer format extensions like SRF are still easy to implement in one > > > > > > file. > > > > > > > (2) The abstract result printer parent class can always implement > > > > > > fallback > > > > > > > methods, so that non-core printers are compatible to new SMW versions > > > > > > even > > > > > > > if they do not support this meta-data yet. > > > > > > > > * The task then boils down to getting a printer object for a given > > > > > > printer > > > > > > > identifier (like "ul"). In order to be perfectly compatible with SMW, > > > > > > this > > > > > > > should be done by calling SMWQueryProcessor::getResultPrinter(). The > > > > problem is that this function currently requires further parameters: > > > > especially it depends on the query result. This is not really needed > > > > and can be avoided with some extra coding from my side. > > > > > > > > * What remains to discuss is what meta information it is that each > > > > > > printer > > > > > > > should provide. A human readable name would be a good start, I guess. > > > > Another useful feature might be a function that returns the list of > > > > supported additional parameters with a short "signature" to indicate > > > > > > their > > > > > > > input type (How should this look? How do you get labels/descriptions > > > > for these parameters?). Anything else? > > > > > > > > I think I can provide the implementation over the weekend then. > > > > > > > > -- Markus > > > > > > > > > -Yaron > > > > > > > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann < > hei...@on...> > > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I am working on our query front-end for inline ask queries which, > > > > > > in the next version, immediately shows your result set while you > > > > > > are creating your query. > > > > > > In order to (dynamically) support all available result printers > and > > > > > > to > > > > > > > > > not hardcode all this stuff which might change in the future I > > > > > > found the array holding name and class of each available result > > > > > > printer ($smwgResultFormats). That's pretty cool but I cannot get > > > > > > additional meta information for each printer. > > > > > > > > > > > > I doubt that users understand that "ul" stands for "unordered > list" > > > > > > so > > > > > > > > > I would love to have a short description (maybe also a longer > one) > > > > > > method for each result printer. > > > > > > Also, some printers support additional parameters which are > > > > > > necessary for the frontend to know about. Here, a second method > > > > > > would be nice > > > > > > to > > > > > > > > > have in order to not hard-code this information. > > > > > > > > > > > > What do you think about these additions? > > > > > > > > > > > > cheers, > > > > > > Jörg > > > > > > ----------------------------------------------------------------------- > > > > > > > > >-- ----- _______________________________________________ > > > > > > Semediawiki-devel mailing list > > > > > > Sem...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > > -- > > > Markus Krötzsch > > > Semantic MediaWiki http://semantic-mediawiki.org > > > http://korrekt.org ma...@se... > > > -- > Markus Krötzsch > Semantic MediaWiki http://semantic-mediawiki.org > http://korrekt.org ma...@se... > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > |
From: Yaron K. <ya...@gm...> - 2009-04-06 20:56:46
|
Markus - I think any info on the type of the parameter can just be part of the parameter description; an example would be, for the "zoom" parameter of the "googlemap" format, "The zoom level of the map (must be an integer between 1 and 18, with '1' being the furthest away)". Sergey - it's true that creating a good UI is hard, but I don't think having each format provide its own forms is the way to go - first because it's a lot more work, and second because, if we do come up with a good UI, I bet it'll be fine across all formats. To illustrate my point for both, I put together a mockup of what a simple interface, using the parameter declarations, could look like. Using Javascript, the form would change the set of parameters available for the user to fill out every time they re-selected a format from the dropdown. Here's what it would look like if the user selected the 'list' format: http://discoursedb.org/new-special-ask.png -Yaron On Mon, Apr 6, 2009 at 10:57 AM, Sergey Chernyshev < ser...@gm...> wrote: > Hey, I'm back from San Francisco and what I find? the Special:Ask > discussion is getting hot ;) > > I have a few things to input - my experience shows that building universal > UI builder is a hard thing to do - Yaron can probably second that. My > approach to this problem before was to have subclasses build their own forms > and parse their own parameters, similar to how extending MW preferences > interface is done. > > This is a way to avoid new constants and constraints on input UI parameters > for specific query printers, more over, since all of this functionality is > implemented in PHP and not reading user-generated content within the pages, > I think it makes the most sense to just leave it to subclassing approach > which will allow more flexibility for SRF implementors. > > Thank you, > > Sergey > > > -- > Sergey Chernyshev > http://www.sergeychernyshev.com/ > > > On Mon, Apr 6, 2009 at 10:01 AM, Markus Krötzsch < > ma...@se...> wrote: > >> I am convinced :-). What remains unclear to me is how to report the >> expected >> input type of a parameter to a UI-creating interface. The types are not >> really >> standard things like "integer" and "string" but also things like "some >> template name" or "the name of a property printout in the query". Should >> we >> introduce yet another system of type constants? >> >> -- Markus >> >> On Montag, 6. April 2009, Yaron Koren wrote: >> > Hi, >> > >> > This is great - the self-description/"reflection" feature will be allow >> for >> > a big improvement to Special:Ask (and evidently Halo as well). This, in >> > addition to Sergey's previous changes, turns Special:Ask from somewhat >> of a >> > hacker interface to an easy-to-use entry point for those getting started >> > with Semantic MediaWiki and inline queries. Actually, the more I think >> > about it, the more I think this is a big step forward in turning SMW >> into a >> > real consumer application, since it will mean that people can run (and >> > administrators can save) queries on the data without needing to read >> > through a lot of documentation. >> > >> > To that end, I would say that yes, there should be descriptive labels >> for >> > each printer, retrieved from message files - just as there should be >> labels >> > for each parameter. Having good inline help is very common among mature >> > software applications - it's considerably easier to use than a user >> > handbook. Obviously, it becomes an issue if someone wants to put whole >> > paragraphs or even pages into the application, but a simple one-sentence >> > description of each concept is, I think, completely reasonable. And I >> > should note another veery important reason to put such information into >> the >> > application - to enable translation; which should make creating inline >> > queries quite a bit easier for those who can't speak English. >> > >> > Finally, if you're at all considering adding more meta-data to each >> > printer, let me suggest another field: a "default limit" value, which >> would >> > override the wiki's value for $smwgQDefaultLimit (though not a "limit=" >> > parameter set in the query). This would allow the "math" formats in SRF >> > (sum, average, min, max) to considerably raise the number of values >> passed >> > in to them by default, since all of them, especially 'sum', require all >> > values to be passed in to produce a meaningful result. It would >> similarly >> > be helpful for 'calendar'. A default limit value could also be helpful >> for >> > the export formats (csv, json, icalendar, rss), although for them >> there's >> > already a workaround because they create, essentially, a link to >> > themselves, with that link setting the correct limit. >> > >> > -Yaron >> > >> > >> > On Sun, Apr 5, 2009 at 12:24 PM, Markus Krötzsch < >> > >> > ma...@se...> wrote: >> > > As promised, SMW has now been updated to support some of the requested >> > > functionalities: >> > > >> > > * To get the list of all available formats, access $smwgResultFormats. >> > > * To get a result printer object, use >> > > SMWQueryProcessor::getResultPrinter(). >> > > * To get the name of a printer object, use $printer->getName(). >> > > >> > > The new functions are documented in the code (or see the API docs). >> > > >> > > The format selector for Special:Ask has been improved to use these >> > > features. >> > > Note that not all SRF formats provide localised names yet; examples on >> > > how to >> > > add translations are found in all SMW result printers and in some of >> the >> > > SRF >> > > printers. >> > > >> > > There was also another change: printers that only show download links >> > > when used inline can indicate to SMW that no query needs to be >> executed >> > > in this case. To do this, simply implement the method getQueryMode() >> as >> > > e.g. in SMW_QP_CSV.php. If you do not do this, SMW will always compute >> > > all query results, even if the printer ignores them anyway. >> > > >> > > Besides Name and QueryMode, no further meta-data has been added. >> > > Especially, I >> > > do not know yet how to provide information about available parameters. >> > > There >> > > is a list of parameter identifiers, but what else should be there for >> > > each of >> > > them: localised labels, expected type of input, anything else? Also, I >> > > was unsure whether longer descriptions besides the names should be >> > > available for >> > > printers -- doing this feels like moving the user handbook to the >> message >> > > file. >> > > >> > > Cheers, >> > > >> > > Markus >> > > >> > > On Donnerstag, 2. April 2009, Markus Krötzsch wrote: >> > > > On Mittwoch, 1. April 2009, Yaron Koren wrote: >> > > > > I think a way for formats to publish both a description of >> themselves >> > > >> > > and >> > > >> > > > > the set of parameters they take would be very helpful: it could be >> > > > > that the easiest way to do it is just to expand the information >> that >> > > > > $smwgResultFormats holds, although maybe the better solution is, >> as >> > > > > you suggest, to add methods like getDescription() and >> > > > > getAllowedParams() to the SMWResultPrinter class, and allow any >> > > > > format class to override >> > > >> > > these >> > > >> > > > > methods. >> > > > >> > > > I also agree with Jörg's observation. I strongly favour Yaron's >> second >> > > > proposal: extending the printer class instead of extending the >> static >> > > > array. A related solution has been in my mind for some time, but I >> did >> > > >> > > not >> > > >> > > > find time to implement it yet: >> > > > >> > > > * In order to keep the information that is available for each result >> > > > printer flexible and extendible, it would be best if the printer >> > > > objects would implement access methods for this information. Two >> main >> > > > advantages are: >> > > > >> > > > (1) The meta information is kept with the code of the printer class, >> so >> > > > printer format extensions like SRF are still easy to implement in >> one >> > > >> > > file. >> > > >> > > > (2) The abstract result printer parent class can always implement >> > > >> > > fallback >> > > >> > > > methods, so that non-core printers are compatible to new SMW >> versions >> > > >> > > even >> > > >> > > > if they do not support this meta-data yet. >> > > > >> > > > * The task then boils down to getting a printer object for a given >> > > >> > > printer >> > > >> > > > identifier (like "ul"). In order to be perfectly compatible with >> SMW, >> > > >> > > this >> > > >> > > > should be done by calling SMWQueryProcessor::getResultPrinter(). The >> > > > problem is that this function currently requires further parameters: >> > > > especially it depends on the query result. This is not really needed >> > > > and can be avoided with some extra coding from my side. >> > > > >> > > > * What remains to discuss is what meta information it is that each >> > > >> > > printer >> > > >> > > > should provide. A human readable name would be a good start, I >> guess. >> > > > Another useful feature might be a function that returns the list of >> > > > supported additional parameters with a short "signature" to indicate >> > > >> > > their >> > > >> > > > input type (How should this look? How do you get labels/descriptions >> > > > for these parameters?). Anything else? >> > > > >> > > > I think I can provide the implementation over the weekend then. >> > > > >> > > > -- Markus >> > > > >> > > > > -Yaron >> > > > > >> > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann < >> hei...@on...> >> > > >> > > wrote: >> > > > > > Hi, >> > > > > > >> > > > > > I am working on our query front-end for inline ask queries >> which, >> > > > > > in the next version, immediately shows your result set while you >> > > > > > are creating your query. >> > > > > > In order to (dynamically) support all available result printers >> and >> > > >> > > to >> > > >> > > > > > not hardcode all this stuff which might change in the future I >> > > > > > found the array holding name and class of each available result >> > > > > > printer ($smwgResultFormats). That's pretty cool but I cannot >> get >> > > > > > additional meta information for each printer. >> > > > > > >> > > > > > I doubt that users understand that "ul" stands for "unordered >> list" >> > > >> > > so >> > > >> > > > > > I would love to have a short description (maybe also a longer >> one) >> > > > > > method for each result printer. >> > > > > > Also, some printers support additional parameters which are >> > > > > > necessary for the frontend to know about. Here, a second method >> > > > > > would be nice >> > > >> > > to >> > > >> > > > > > have in order to not hard-code this information. >> > > > > > >> > > > > > What do you think about these additions? >> > > > > > >> > > > > > cheers, >> > > > > > Jörg >> > > >> > > >> ----------------------------------------------------------------------- >> > > >> > > > > >-- ----- _______________________________________________ >> > > > > > Semediawiki-devel mailing list >> > > > > > Sem...@li... >> > > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > > >> > > -- >> > > Markus Krötzsch >> > > Semantic MediaWiki http://semantic-mediawiki.org >> > > http://korrekt.org ma...@se... >> >> >> -- >> Markus Krötzsch >> Semantic MediaWiki http://semantic-mediawiki.org >> http://korrekt.org ma...@se... >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> > |
From: Sergey C. <ser...@gm...> - 2009-04-06 21:16:52
|
It's definitely a matter of taste, but there is nothing wrong in going in both directions where superclass implements parametrized input and subclasses implement their own forms if they want - this way there is path for extended solutions in subclasses and still there can be generic implementations in superclass. In any case, it's just a matter of taste - you either fix all possible solutions in superclass and add parametrization or leave it for later simply putting a free-form entry in superclass and letting subclasses to deal with it if they want. As you know, I'm a big Agile supporter and going with every step being the shortest one is what I love - that's why I suggest the subclassing thing ;) Sergey On Mon, Apr 6, 2009 at 4:56 PM, Yaron Koren <ya...@gm...> wrote: > Markus - I think any info on the type of the parameter can just be part of > the parameter description; an example would be, for the "zoom" parameter of > the "googlemap" format, "The zoom level of the map (must be an integer > between 1 and 18, with '1' being the furthest away)". > > Sergey - it's true that creating a good UI is hard, but I don't think > having each format provide its own forms is the way to go - first because > it's a lot more work, and second because, if we do come up with a good UI, I > bet it'll be fine across all formats. > > To illustrate my point for both, I put together a mockup of what a simple > interface, using the parameter declarations, could look like. Using > Javascript, the form would change the set of parameters available for the > user to fill out every time they re-selected a format from the dropdown. > Here's what it would look like if the user selected the 'list' format: > > http://discoursedb.org/new-special-ask.png > > -Yaron > > > > On Mon, Apr 6, 2009 at 10:57 AM, Sergey Chernyshev < > ser...@gm...> wrote: > >> Hey, I'm back from San Francisco and what I find? the Special:Ask >> discussion is getting hot ;) >> >> I have a few things to input - my experience shows that building universal >> UI builder is a hard thing to do - Yaron can probably second that. My >> approach to this problem before was to have subclasses build their own forms >> and parse their own parameters, similar to how extending MW preferences >> interface is done. >> >> This is a way to avoid new constants and constraints on input UI >> parameters for specific query printers, more over, since all of this >> functionality is implemented in PHP and not reading user-generated content >> within the pages, I think it makes the most sense to just leave it to >> subclassing approach which will allow more flexibility for SRF implementors. >> >> Thank you, >> >> Sergey >> >> >> -- >> Sergey Chernyshev >> http://www.sergeychernyshev.com/ >> >> >> On Mon, Apr 6, 2009 at 10:01 AM, Markus Krötzsch < >> ma...@se...> wrote: >> >>> I am convinced :-). What remains unclear to me is how to report the >>> expected >>> input type of a parameter to a UI-creating interface. The types are not >>> really >>> standard things like "integer" and "string" but also things like "some >>> template name" or "the name of a property printout in the query". Should >>> we >>> introduce yet another system of type constants? >>> >>> -- Markus >>> >>> On Montag, 6. April 2009, Yaron Koren wrote: >>> > Hi, >>> > >>> > This is great - the self-description/"reflection" feature will be allow >>> for >>> > a big improvement to Special:Ask (and evidently Halo as well). This, in >>> > addition to Sergey's previous changes, turns Special:Ask from somewhat >>> of a >>> > hacker interface to an easy-to-use entry point for those getting >>> started >>> > with Semantic MediaWiki and inline queries. Actually, the more I think >>> > about it, the more I think this is a big step forward in turning SMW >>> into a >>> > real consumer application, since it will mean that people can run (and >>> > administrators can save) queries on the data without needing to read >>> > through a lot of documentation. >>> > >>> > To that end, I would say that yes, there should be descriptive labels >>> for >>> > each printer, retrieved from message files - just as there should be >>> labels >>> > for each parameter. Having good inline help is very common among mature >>> > software applications - it's considerably easier to use than a user >>> > handbook. Obviously, it becomes an issue if someone wants to put whole >>> > paragraphs or even pages into the application, but a simple >>> one-sentence >>> > description of each concept is, I think, completely reasonable. And I >>> > should note another veery important reason to put such information into >>> the >>> > application - to enable translation; which should make creating inline >>> > queries quite a bit easier for those who can't speak English. >>> > >>> > Finally, if you're at all considering adding more meta-data to each >>> > printer, let me suggest another field: a "default limit" value, which >>> would >>> > override the wiki's value for $smwgQDefaultLimit (though not a "limit=" >>> > parameter set in the query). This would allow the "math" formats in SRF >>> > (sum, average, min, max) to considerably raise the number of values >>> passed >>> > in to them by default, since all of them, especially 'sum', require all >>> > values to be passed in to produce a meaningful result. It would >>> similarly >>> > be helpful for 'calendar'. A default limit value could also be helpful >>> for >>> > the export formats (csv, json, icalendar, rss), although for them >>> there's >>> > already a workaround because they create, essentially, a link to >>> > themselves, with that link setting the correct limit. >>> > >>> > -Yaron >>> > >>> > >>> > On Sun, Apr 5, 2009 at 12:24 PM, Markus Krötzsch < >>> > >>> > ma...@se...> wrote: >>> > > As promised, SMW has now been updated to support some of the >>> requested >>> > > functionalities: >>> > > >>> > > * To get the list of all available formats, access >>> $smwgResultFormats. >>> > > * To get a result printer object, use >>> > > SMWQueryProcessor::getResultPrinter(). >>> > > * To get the name of a printer object, use $printer->getName(). >>> > > >>> > > The new functions are documented in the code (or see the API docs). >>> > > >>> > > The format selector for Special:Ask has been improved to use these >>> > > features. >>> > > Note that not all SRF formats provide localised names yet; examples >>> on >>> > > how to >>> > > add translations are found in all SMW result printers and in some of >>> the >>> > > SRF >>> > > printers. >>> > > >>> > > There was also another change: printers that only show download links >>> > > when used inline can indicate to SMW that no query needs to be >>> executed >>> > > in this case. To do this, simply implement the method getQueryMode() >>> as >>> > > e.g. in SMW_QP_CSV.php. If you do not do this, SMW will always >>> compute >>> > > all query results, even if the printer ignores them anyway. >>> > > >>> > > Besides Name and QueryMode, no further meta-data has been added. >>> > > Especially, I >>> > > do not know yet how to provide information about available >>> parameters. >>> > > There >>> > > is a list of parameter identifiers, but what else should be there for >>> > > each of >>> > > them: localised labels, expected type of input, anything else? Also, >>> I >>> > > was unsure whether longer descriptions besides the names should be >>> > > available for >>> > > printers -- doing this feels like moving the user handbook to the >>> message >>> > > file. >>> > > >>> > > Cheers, >>> > > >>> > > Markus >>> > > >>> > > On Donnerstag, 2. April 2009, Markus Krötzsch wrote: >>> > > > On Mittwoch, 1. April 2009, Yaron Koren wrote: >>> > > > > I think a way for formats to publish both a description of >>> themselves >>> > > >>> > > and >>> > > >>> > > > > the set of parameters they take would be very helpful: it could >>> be >>> > > > > that the easiest way to do it is just to expand the information >>> that >>> > > > > $smwgResultFormats holds, although maybe the better solution is, >>> as >>> > > > > you suggest, to add methods like getDescription() and >>> > > > > getAllowedParams() to the SMWResultPrinter class, and allow any >>> > > > > format class to override >>> > > >>> > > these >>> > > >>> > > > > methods. >>> > > > >>> > > > I also agree with Jörg's observation. I strongly favour Yaron's >>> second >>> > > > proposal: extending the printer class instead of extending the >>> static >>> > > > array. A related solution has been in my mind for some time, but I >>> did >>> > > >>> > > not >>> > > >>> > > > find time to implement it yet: >>> > > > >>> > > > * In order to keep the information that is available for each >>> result >>> > > > printer flexible and extendible, it would be best if the printer >>> > > > objects would implement access methods for this information. Two >>> main >>> > > > advantages are: >>> > > > >>> > > > (1) The meta information is kept with the code of the printer >>> class, so >>> > > > printer format extensions like SRF are still easy to implement in >>> one >>> > > >>> > > file. >>> > > >>> > > > (2) The abstract result printer parent class can always implement >>> > > >>> > > fallback >>> > > >>> > > > methods, so that non-core printers are compatible to new SMW >>> versions >>> > > >>> > > even >>> > > >>> > > > if they do not support this meta-data yet. >>> > > > >>> > > > * The task then boils down to getting a printer object for a given >>> > > >>> > > printer >>> > > >>> > > > identifier (like "ul"). In order to be perfectly compatible with >>> SMW, >>> > > >>> > > this >>> > > >>> > > > should be done by calling SMWQueryProcessor::getResultPrinter(). >>> The >>> > > > problem is that this function currently requires further >>> parameters: >>> > > > especially it depends on the query result. This is not really >>> needed >>> > > > and can be avoided with some extra coding from my side. >>> > > > >>> > > > * What remains to discuss is what meta information it is that each >>> > > >>> > > printer >>> > > >>> > > > should provide. A human readable name would be a good start, I >>> guess. >>> > > > Another useful feature might be a function that returns the list of >>> > > > supported additional parameters with a short "signature" to >>> indicate >>> > > >>> > > their >>> > > >>> > > > input type (How should this look? How do you get >>> labels/descriptions >>> > > > for these parameters?). Anything else? >>> > > > >>> > > > I think I can provide the implementation over the weekend then. >>> > > > >>> > > > -- Markus >>> > > > >>> > > > > -Yaron >>> > > > > >>> > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann < >>> hei...@on...> >>> > > >>> > > wrote: >>> > > > > > Hi, >>> > > > > > >>> > > > > > I am working on our query front-end for inline ask queries >>> which, >>> > > > > > in the next version, immediately shows your result set while >>> you >>> > > > > > are creating your query. >>> > > > > > In order to (dynamically) support all available result printers >>> and >>> > > >>> > > to >>> > > >>> > > > > > not hardcode all this stuff which might change in the future I >>> > > > > > found the array holding name and class of each available result >>> > > > > > printer ($smwgResultFormats). That's pretty cool but I cannot >>> get >>> > > > > > additional meta information for each printer. >>> > > > > > >>> > > > > > I doubt that users understand that "ul" stands for "unordered >>> list" >>> > > >>> > > so >>> > > >>> > > > > > I would love to have a short description (maybe also a longer >>> one) >>> > > > > > method for each result printer. >>> > > > > > Also, some printers support additional parameters which are >>> > > > > > necessary for the frontend to know about. Here, a second method >>> > > > > > would be nice >>> > > >>> > > to >>> > > >>> > > > > > have in order to not hard-code this information. >>> > > > > > >>> > > > > > What do you think about these additions? >>> > > > > > >>> > > > > > cheers, >>> > > > > > Jörg >>> > > >>> > > >>> ----------------------------------------------------------------------- >>> > > >>> > > > > >-- ----- _______________________________________________ >>> > > > > > Semediawiki-devel mailing list >>> > > > > > Sem...@li... >>> > > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>> > > >>> > > -- >>> > > Markus Krötzsch >>> > > Semantic MediaWiki http://semantic-mediawiki.org >>> > > http://korrekt.org ma...@se... >>> >>> >>> -- >>> Markus Krötzsch >>> Semantic MediaWiki http://semantic-mediawiki.org >>> http://korrekt.org ma...@se... >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Semediawiki-devel mailing list >>> Sem...@li... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>> >>> >> > |
From: Markus K. <ma...@se...> - 2009-04-07 07:40:44
|
On Montag, 6. April 2009, Yaron Koren wrote: > Markus - I think any info on the type of the parameter can just be part of > the parameter description; an example would be, for the "zoom" parameter of > the "googlemap" format, "The zoom level of the map (must be an integer > between 1 and 18, with '1' being the furthest away)". Indeed, this would be a good start. > > Sergey - it's true that creating a good UI is hard, but I don't think > having each format provide its own forms is the way to go - first because > it's a lot more work, and second because, if we do come up with a good UI, > I bet it'll be fine across all formats. I tend to agree here. The biggest drawback I see with the "class-generated form" option is that you get only one possible form. This is useful for MW prefs, since the UI into which the forms are embedded is known and fairly stable. But I think one of the main motivations of extensions like Halo is to improve the UI in new and fancy ways (e.g. with auto completion). If printers were to ship ready-made forms, then Halo would not have much freedom to design new interfaces, and the task of improving UI functionality would become a responsibility of the printer developers (including me ;-). This is why I would prefer an approach where only the relevant parameters are exported, and the form construction is left to the code using this. I think the following API would be most extensible and convenient: * Have a function that returns an array of parameter names. * Have further functions to retrieve extra information about a particular parameter (the input would be the parameter name). Examples include getParameterLabel(), getParameterDescription(), and maybe, one day, getParameterType(). > > To illustrate my point for both, I put together a mockup of what a simple > interface, using the parameter declarations, could look like. Using > Javascript, the form would change the set of parameters available for the > user to fill out every time they re-selected a format from the dropdown. > Here's what it would look like if the user selected the 'list' format: > > http://discoursedb.org/new-special-ask.png Frankly, the first thing I would change for an improved Special:Ask would be the two topmost text inputs. Especially adding printouts should be easier and more structured. But Special:Ask so far was not meant to be very user friendly, but rather as a web service that "further results" and data exports can link to. I think it would be worth cleaning up the code (Special:Ask is still rather messy) and then consider separating the UI aspects more clearly from the web service aspects, maybe far enough to allow for simple subclassing and customisation of the whole special page. -- Markus > > -Yaron > > > On Mon, Apr 6, 2009 at 10:57 AM, Sergey Chernyshev < > > ser...@gm...> wrote: > > Hey, I'm back from San Francisco and what I find? the Special:Ask > > discussion is getting hot ;) > > > > I have a few things to input - my experience shows that building > > universal UI builder is a hard thing to do - Yaron can probably second > > that. My approach to this problem before was to have subclasses build > > their own forms and parse their own parameters, similar to how extending > > MW preferences interface is done. > > > > This is a way to avoid new constants and constraints on input UI > > parameters for specific query printers, more over, since all of this > > functionality is implemented in PHP and not reading user-generated > > content within the pages, I think it makes the most sense to just leave > > it to subclassing approach which will allow more flexibility for SRF > > implementors. > > > > Thank you, > > > > Sergey > > > > > > -- > > Sergey Chernyshev > > http://www.sergeychernyshev.com/ > > > > > > On Mon, Apr 6, 2009 at 10:01 AM, Markus Krötzsch < > > > > ma...@se...> wrote: > >> I am convinced :-). What remains unclear to me is how to report the > >> expected > >> input type of a parameter to a UI-creating interface. The types are not > >> really > >> standard things like "integer" and "string" but also things like "some > >> template name" or "the name of a property printout in the query". Should > >> we > >> introduce yet another system of type constants? > >> > >> -- Markus > >> > >> On Montag, 6. April 2009, Yaron Koren wrote: > >> > Hi, > >> > > >> > This is great - the self-description/"reflection" feature will be > >> > allow > >> > >> for > >> > >> > a big improvement to Special:Ask (and evidently Halo as well). This, > >> > in addition to Sergey's previous changes, turns Special:Ask from > >> > somewhat > >> > >> of a > >> > >> > hacker interface to an easy-to-use entry point for those getting > >> > started with Semantic MediaWiki and inline queries. Actually, the more > >> > I think about it, the more I think this is a big step forward in > >> > turning SMW > >> > >> into a > >> > >> > real consumer application, since it will mean that people can run (and > >> > administrators can save) queries on the data without needing to read > >> > through a lot of documentation. > >> > > >> > To that end, I would say that yes, there should be descriptive labels > >> > >> for > >> > >> > each printer, retrieved from message files - just as there should be > >> > >> labels > >> > >> > for each parameter. Having good inline help is very common among > >> > mature software applications - it's considerably easier to use than a > >> > user handbook. Obviously, it becomes an issue if someone wants to put > >> > whole paragraphs or even pages into the application, but a simple > >> > one-sentence description of each concept is, I think, completely > >> > reasonable. And I should note another veery important reason to put > >> > such information into > >> > >> the > >> > >> > application - to enable translation; which should make creating inline > >> > queries quite a bit easier for those who can't speak English. > >> > > >> > Finally, if you're at all considering adding more meta-data to each > >> > printer, let me suggest another field: a "default limit" value, which > >> > >> would > >> > >> > override the wiki's value for $smwgQDefaultLimit (though not a > >> > "limit=" parameter set in the query). This would allow the "math" > >> > formats in SRF (sum, average, min, max) to considerably raise the > >> > number of values > >> > >> passed > >> > >> > in to them by default, since all of them, especially 'sum', require > >> > all values to be passed in to produce a meaningful result. It would > >> > >> similarly > >> > >> > be helpful for 'calendar'. A default limit value could also be helpful > >> > >> for > >> > >> > the export formats (csv, json, icalendar, rss), although for them > >> > >> there's > >> > >> > already a workaround because they create, essentially, a link to > >> > themselves, with that link setting the correct limit. > >> > > >> > -Yaron > >> > > >> > > >> > On Sun, Apr 5, 2009 at 12:24 PM, Markus Krötzsch < > >> > > >> > ma...@se...> wrote: > >> > > As promised, SMW has now been updated to support some of the > >> > > requested functionalities: > >> > > > >> > > * To get the list of all available formats, access > >> > > $smwgResultFormats. * To get a result printer object, use > >> > > SMWQueryProcessor::getResultPrinter(). > >> > > * To get the name of a printer object, use $printer->getName(). > >> > > > >> > > The new functions are documented in the code (or see the API docs). > >> > > > >> > > The format selector for Special:Ask has been improved to use these > >> > > features. > >> > > Note that not all SRF formats provide localised names yet; examples > >> > > on how to > >> > > add translations are found in all SMW result printers and in some of > >> > >> the > >> > >> > > SRF > >> > > printers. > >> > > > >> > > There was also another change: printers that only show download > >> > > links when used inline can indicate to SMW that no query needs to be > >> > >> executed > >> > >> > > in this case. To do this, simply implement the method getQueryMode() > >> > >> as > >> > >> > > e.g. in SMW_QP_CSV.php. If you do not do this, SMW will always > >> > > compute all query results, even if the printer ignores them anyway. > >> > > > >> > > Besides Name and QueryMode, no further meta-data has been added. > >> > > Especially, I > >> > > do not know yet how to provide information about available > >> > > parameters. There > >> > > is a list of parameter identifiers, but what else should be there > >> > > for each of > >> > > them: localised labels, expected type of input, anything else? Also, > >> > > I was unsure whether longer descriptions besides the names should be > >> > > available for > >> > > printers -- doing this feels like moving the user handbook to the > >> > >> message > >> > >> > > file. > >> > > > >> > > Cheers, > >> > > > >> > > Markus > >> > > > >> > > On Donnerstag, 2. April 2009, Markus Krötzsch wrote: > >> > > > On Mittwoch, 1. April 2009, Yaron Koren wrote: > >> > > > > I think a way for formats to publish both a description of > >> > >> themselves > >> > >> > > and > >> > > > >> > > > > the set of parameters they take would be very helpful: it could > >> > > > > be that the easiest way to do it is just to expand the > >> > > > > information > >> > >> that > >> > >> > > > > $smwgResultFormats holds, although maybe the better solution is, > >> > >> as > >> > >> > > > > you suggest, to add methods like getDescription() and > >> > > > > getAllowedParams() to the SMWResultPrinter class, and allow any > >> > > > > format class to override > >> > > > >> > > these > >> > > > >> > > > > methods. > >> > > > > >> > > > I also agree with Jörg's observation. I strongly favour Yaron's > >> > >> second > >> > >> > > > proposal: extending the printer class instead of extending the > >> > >> static > >> > >> > > > array. A related solution has been in my mind for some time, but I > >> > >> did > >> > >> > > not > >> > > > >> > > > find time to implement it yet: > >> > > > > >> > > > * In order to keep the information that is available for each > >> > > > result printer flexible and extendible, it would be best if the > >> > > > printer objects would implement access methods for this > >> > > > information. Two > >> > >> main > >> > >> > > > advantages are: > >> > > > > >> > > > (1) The meta information is kept with the code of the printer > >> > > > class, > >> > >> so > >> > >> > > > printer format extensions like SRF are still easy to implement in > >> > >> one > >> > >> > > file. > >> > > > >> > > > (2) The abstract result printer parent class can always implement > >> > > > >> > > fallback > >> > > > >> > > > methods, so that non-core printers are compatible to new SMW > >> > >> versions > >> > >> > > even > >> > > > >> > > > if they do not support this meta-data yet. > >> > > > > >> > > > * The task then boils down to getting a printer object for a given > >> > > > >> > > printer > >> > > > >> > > > identifier (like "ul"). In order to be perfectly compatible with > >> > >> SMW, > >> > >> > > this > >> > > > >> > > > should be done by calling SMWQueryProcessor::getResultPrinter(). > >> > > > The problem is that this function currently requires further > >> > > > parameters: especially it depends on the query result. This is not > >> > > > really needed and can be avoided with some extra coding from my > >> > > > side. > >> > > > > >> > > > * What remains to discuss is what meta information it is that each > >> > > > >> > > printer > >> > > > >> > > > should provide. A human readable name would be a good start, I > >> > >> guess. > >> > >> > > > Another useful feature might be a function that returns the list > >> > > > of supported additional parameters with a short "signature" to > >> > > > indicate > >> > > > >> > > their > >> > > > >> > > > input type (How should this look? How do you get > >> > > > labels/descriptions for these parameters?). Anything else? > >> > > > > >> > > > I think I can provide the implementation over the weekend then. > >> > > > > >> > > > -- Markus > >> > > > > >> > > > > -Yaron > >> > > > > > >> > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann < > >> > >> hei...@on...> > >> > >> > > wrote: > >> > > > > > Hi, > >> > > > > > > >> > > > > > I am working on our query front-end for inline ask queries > >> > >> which, > >> > >> > > > > > in the next version, immediately shows your result set while > >> > > > > > you are creating your query. > >> > > > > > In order to (dynamically) support all available result > >> > > > > > printers > >> > >> and > >> > >> > > to > >> > > > >> > > > > > not hardcode all this stuff which might change in the future I > >> > > > > > found the array holding name and class of each available > >> > > > > > result printer ($smwgResultFormats). That's pretty cool but I > >> > > > > > cannot > >> > >> get > >> > >> > > > > > additional meta information for each printer. > >> > > > > > > >> > > > > > I doubt that users understand that "ul" stands for "unordered > >> > >> list" > >> > >> > > so > >> > > > >> > > > > > I would love to have a short description (maybe also a longer > >> > >> one) > >> > >> > > > > > method for each result printer. > >> > > > > > Also, some printers support additional parameters which are > >> > > > > > necessary for the frontend to know about. Here, a second > >> > > > > > method would be nice > >> > > > >> > > to > >> > > > >> > > > > > have in order to not hard-code this information. > >> > > > > > > >> > > > > > What do you think about these additions? > >> > > > > > > >> > > > > > cheers, > >> > > > > > Jörg > >> > >> ----------------------------------------------------------------------- > >> > >> > > > > >-- ----- _______________________________________________ > >> > > > > > Semediawiki-devel mailing list > >> > > > > > Sem...@li... > >> > > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > >> > > > >> > > -- > >> > > Markus Krötzsch > >> > > Semantic MediaWiki http://semantic-mediawiki.org > >> > > http://korrekt.org ma...@se... > >> > >> -- > >> Markus Krötzsch > >> Semantic MediaWiki http://semantic-mediawiki.org > >> http://korrekt.org ma...@se... > >> > >> > >> > >> ------------------------------------------------------------------------ > >>------ > >> > >> _______________________________________________ > >> Semediawiki-devel mailing list > >> Sem...@li... > >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org ma...@se... |
From: Sergey C. <ser...@gm...> - 2009-04-07 17:01:38
|
On Tue, Apr 7, 2009 at 3:40 AM, Markus Krötzsch < ma...@se...> wrote: > On Montag, 6. April 2009, Yaron Koren wrote: > [skip-skip] > > Sergey - it's true that creating a good UI is hard, but I don't think > > having each format provide its own forms is the way to go - first because > > it's a lot more work, and second because, if we do come up with a good > UI, > > I bet it'll be fine across all formats. > > I tend to agree here. The biggest drawback I see with the "class-generated > form" option is that you get only one possible form. This is useful for MW > prefs, since the UI into which the forms are embedded is known and fairly > stable. But I think one of the main motivations of extensions like Halo is > to > improve the UI in new and fancy ways (e.g. with auto completion). If > printers > were to ship ready-made forms, then Halo would not have much freedom to > design > new interfaces, and the task of improving UI functionality would become a > responsibility of the printer developers (including me ;-). This is why I > would prefer an approach where only the relevant parameters are exported, > and > the form construction is left to the code using this. > > I think the following API would be most extensible and convenient: > > * Have a function that returns an array of parameter names. > * Have further functions to retrieve extra information about a particular > parameter (the input would be the parameter name). Examples include > getParameterLabel(), getParameterDescription(), and maybe, one day, > getParameterType(). Guys, I'll leave it up to you to take care of architecture - as long as stuff gets improved, I'm fine with it ;) > > To illustrate my point for both, I put together a mockup of what a simple > > interface, using the parameter declarations, could look like. Using > > Javascript, the form would change the set of parameters available for the > > user to fill out every time they re-selected a format from the dropdown. > > Here's what it would look like if the user selected the 'list' format: > > > > http://discoursedb.org/new-special-ask.png > > > > > Frankly, the first thing I would change for an improved Special:Ask would > be > the two topmost text inputs. Especially adding printouts should be easier > and > more structured. But Special:Ask so far was not meant to be very user > friendly, but rather as a web service that "further results" and data > exports > can link to. I think it would be worth cleaning up the code (Special:Ask is > still rather messy) and then consider separating the UI aspects more > clearly > from the web service aspects, maybe far enough to allow for simple > subclassing > and customisation of the whole special page. I think it's important to actively show Special:Ask to people as it represents main feature of SMW - ability to use you wiki as data, easily extract accumulated knowledge, format it as you want, and post it to other pages (instead of "wikipedia category hell"). There are definitely a few things to improve on top boxes, but they work already, but setting additional parameters so results can be copied to a wiki page (using code embed I just checked in) still not functioning so I'd go for adding the parameters first and improve overall UI next. > > -- Markus > Sergey |