Re: [SMW-devel] New feature: Query control and query permissions
> SMW 1.2 extends the options for controlling which queries users are allowed
> to
> ask, and it has a mechanism that can be used to let some users ask more than
> others ("permissions").
>
> The detailed query control settings are achieved by the new configuration
> parameter $smwgQFeatures. This parameter defines which query features are
> allowed in #ask. The default is the following:
>
> $smwgQFeatures = SMW_PROPERTY_QUERY | SMW_CATEGORY_QUERY | SMW_CONCEPT_QUERY |
> SMW_NAMESPACE_QUERY | SMW_CONJUNCTION_QUERY | SMW_DISJUNCTION_QUERY;
>
> This allows all existing features to be used. Other possible settings could
> be:
>
> only category intersections:
> $smwgQFeatures = SMW_CATEGORY_QUERY | SMW_CONJUNCTION_QUERY;
>
> only single concepts: (see earlier mail on concepts)
> $smwgQFeatures = SMW_CONCEPT_QUERY;
>
> anything but disjunctions:
> $smwgQFeatures = SMW_ANY_QUERY & ~SMW_DISJUNCTION_QUERY;
>
> So you can very clearly customise SMW queries. This affects only the #ask
> queries. Queries stored as concepts have their own setting, called
> $smwgQConceptFeatures. For example, concepts currently are not allowed to
> refer to other concepts (recursion is not handled properly by SMW yet).
>
> This gives you a way to restrict query creation to some user group of the
> wiki:
>
> * set $smwgQFeatures = SMW_CONCEPT_QUERY;
> * configure MediaWiki to have the Concept: namespace being editable only by
> some user groups (there are extensions for that, I have no further details
> here, search the web).
>
> Then #ask queries can only use single concepts and not be used to invent any
> new queries. So you can have very complex queries, but have responsible
> people creating them and making sure they are fine and fast in the wiki. You
> can also set $smwgQFeatures = SMW_CONCEPT_QUERY | SMW_CONJUNCTION_QUERY; to
> allow for conjunctions of multiple concepts, if desired, or you can further
> include categories. This appears to be a good option especially for very
> large sites that cannot afford users toying around with arbitrary queries for
> reasons of performance. This restriction was not tested thoroughly yet (so do
> not rely on this performance safety).
>
> Restricting complex queries to concept will become even more useful as soon
> as
> SMW 1.3 offers concept-specific caching (e.g. some concepts being precomputed
> in the database so they can be recalled like categories). Category caching
> was originally planned for SMW 1.2 already, but we decided to first introduce
> concepts and then have a general caching mechanism for them. In this way, all
> queries will be cacheable and scale to any site that is able to display
> categories. Wikipedia comes to mind. But one more release is needed for that
> to be done properly.
>
>
> Cheers,
>
> Markus
>
>
Concept namespace with access control and especially caching of it is a
great feature!
I hope also that automatical creation of properties with metadata (eg
page creation, page
modification) can be implemented. Also, Jon Lang proposal to introduce
"duplicate" and "find"
#ask attributes is cool, it makes SMW more SQLish, which extends it's
flexibility.
(Just to show my support).
Dmitriy
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] New feature: Query control and query permissions
Hi Markus
that sounds very interesting. As it will take a while before I can move to the
new version I'm wondering if these new features would allow me to combine query
results (e.g. using SMW_CONJUNCTION_QUERY and
SMW_DISJUNCTION_QUERY) as in the example below. I'm not sure because if I
understand the new features correctly they are more about storing the query
(syntax) itself rather than the actual result?
So could one do something like this theoretical example:
For instance if I have a wiki which stores workshop details.
There are events held in different countries at different times which offer a
possibly overlapping range of workshops. The wiki contains pages for the
workshops with their details stored as semantic data.
Someone is during spring (6.3. to 13.4.) in Paris (France), during summer
(6.6.-21.7.) in Berlin (Germany) and during autumn (1.10.-23.11) anywhere in the
UK. In order to avoid to sit in workshops during the hot summer he wants to find
those workshops offered in Germany during the summer which he doesn't need to
attend because they are also offered during the cooler seasons in the two other
countries.
Right now I would have one simple general form on a query page (called
'workshops') which would allow to select a start and end date, as well as a
place (a city and a country), and a combine method and then searches for
workshops at the indicated time period in the selected place (and save the
result using the specified combine method).
So the query would in principal look like this:
{{#ask: [[Category:Workshop]] | [[start::>{{#var:startdate}}]]
[[end::<{{#var:enddate}}]] [[place::{{#var:city}};{{#var:country}}]] |
store_as={{PAGENAME}} | combine={{#var:method}} }}
The heat sensitive person would now run the query three times with his three
sets of travel details:
1st query:
startdate = 6 March 2009
enddate = 13 April 2009
city = Paris
country = France
method = replace (default)
executing:
{{#ask: [[Category:Workshop]] | [[start::>6 March 2009]] [[end::<13 April 2009]]
[[place::Paris;France]] | store_as={{PAGENAME}} | combine=replace }}
this result (= list of workshop page titles) is first saved under the name
'workshops' in the database
2nd query:
startdate = 1 October 2009
enddate = 23 November 2009
city = ?
country = UK
method = union
executing:
{{#ask: [[Category:Workshop]] | [[start::>1 October 2009]] [[end::<23 November
2009]] [[place::?;UK]] | store_as={{PAGENAME}} | combine=union }}
this result (= list of workshop page titles) is combined by 'union' with the
existing 'workshops' result set and the combined result is saved.
3rd query:
startdate = 9 June 2009
enddate = 21 July 2009
city = Berlin
country = Germany
method = intersect
{{#ask: [[Category:Workshop]] | [[start::>9 June 2009]] [[end::<21 July 2009]]
[[place::Berlin;Germany]] | store_as={{PAGENAME}} | combine=intersect }}
this result (= list of workshop page titles) is combined by 'intersect' with the
existing 'workshops' result set and the combined result is now the desired list
of workshops which to avoid in Berlin and can be displayed.
(Or alternatively using method 'not_in' to select workshops which are only
offered in Germany).
I'm not sure if e.g. queries using SMW_CONJUNCTION_QUERY and
SMW_DISJUNCTION_QUERY and the new query saving features could be used to achieve
a similar result?
Cheers,
Gu
Quoting Markus Krötzsch <[EMAIL PROTECTED]>:
> SMW 1.2 extends the options for controlling which queries users are allowed
> to
> ask, and it has a mechanism that can be used to let some users ask more than
>
> others ("permissions").
>
> The detailed query control settings are achieved by the new configuration
> parameter $smwgQFeatures. This parameter defines which query features are
> allowed in #ask. The default is the following:
>
> $smwgQFeatures = SMW_PROPERTY_QUERY | SMW_CATEGORY_QUERY | SMW_CONCEPT_QUERY
> |
> SMW_NAMESPACE_QUERY | SMW_CONJUNCTION_QUERY |
> SMW_DISJUNCTION_QUERY;
>
> This allows all existing features to be used. Other possible settings could
> be:
>
> only category intersections:
> $smwgQFeatures = SMW_CATEGORY_QUERY | SMW_CONJUNCTION_QUERY;
>
> only single concepts: (see earlier mail on concepts)
> $smwgQFeatures = SMW_CONCEPT_QUERY;
>
> anything but disjunctions:
> $smwgQFeatures = SMW_ANY_QUERY & ~SMW_DISJUNCTION_QUERY;
>
> So you can very clearly customise SMW queries. This affects only the #ask
> queries. Queries stored as concepts have their own setting, called
> $smwgQConceptFeatures. For example, concepts currently are not allowed to
> refer to other concepts (recursion is not handled properly by SMW yet).
>
> This gives you a way to restrict query creation to some user group of the
> wiki:
>
> * set $smwgQFeatures = SMW_CONCEPT_QUERY;
> * configure MediaWiki to have the Concept: namespace being editable only by
> some user groups (there are extensions for that, I have no further details
> here, search the web).
>
> Then #ask que
[SMW-devel] New feature: Query control and query permissions
SMW 1.2 extends the options for controlling which queries users are allowed to
ask, and it has a mechanism that can be used to let some users ask more than
others ("permissions").
The detailed query control settings are achieved by the new configuration
parameter $smwgQFeatures. This parameter defines which query features are
allowed in #ask. The default is the following:
$smwgQFeatures = SMW_PROPERTY_QUERY | SMW_CATEGORY_QUERY | SMW_CONCEPT_QUERY |
SMW_NAMESPACE_QUERY | SMW_CONJUNCTION_QUERY | SMW_DISJUNCTION_QUERY;
This allows all existing features to be used. Other possible settings could
be:
only category intersections:
$smwgQFeatures = SMW_CATEGORY_QUERY | SMW_CONJUNCTION_QUERY;
only single concepts: (see earlier mail on concepts)
$smwgQFeatures = SMW_CONCEPT_QUERY;
anything but disjunctions:
$smwgQFeatures = SMW_ANY_QUERY & ~SMW_DISJUNCTION_QUERY;
So you can very clearly customise SMW queries. This affects only the #ask
queries. Queries stored as concepts have their own setting, called
$smwgQConceptFeatures. For example, concepts currently are not allowed to
refer to other concepts (recursion is not handled properly by SMW yet).
This gives you a way to restrict query creation to some user group of the
wiki:
* set $smwgQFeatures = SMW_CONCEPT_QUERY;
* configure MediaWiki to have the Concept: namespace being editable only by
some user groups (there are extensions for that, I have no further details
here, search the web).
Then #ask queries can only use single concepts and not be used to invent any
new queries. So you can have very complex queries, but have responsible
people creating them and making sure they are fine and fast in the wiki. You
can also set $smwgQFeatures = SMW_CONCEPT_QUERY | SMW_CONJUNCTION_QUERY; to
allow for conjunctions of multiple concepts, if desired, or you can further
include categories. This appears to be a good option especially for very
large sites that cannot afford users toying around with arbitrary queries for
reasons of performance. This restriction was not tested thoroughly yet (so do
not rely on this performance safety).
Restricting complex queries to concept will become even more useful as soon as
SMW 1.3 offers concept-specific caching (e.g. some concepts being precomputed
in the database so they can be recalled like categories). Category caching
was originally planned for SMW 1.2 already, but we decided to first introduce
concepts and then have a general caching mechanism for them. In this way, all
queries will be cacheable and scale to any site that is able to display
categories. Wikipedia comes to mind. But one more release is needed for that
to be done properly.
Cheers,
Markus
--
Markus Krötzsch
Semantic MediaWikihttp://semantic-mediawiki.org
http://korrekt.org[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
