Semantic MediaWiki

Asheesh Laroia wrote:
> Is it possible to hide some attributes so that only admins can see them? 

 From what I know of the code, not easily.  When a page is saved, SMW 
parses its annotations and stores the semantic annotations in tables. 
There's a smw_attributes table with the page ID, the property name, and 
its value.  No access control at the database level.

Yes, you could add a special property Only_for_admins and modify the SMW 
code to check this before it does anything with a property.  SMW 1.0 
tends to create a DataValue whenever it deals with a property so the 
change might be well-encapsulated.

HOWEVER,
Normally the User:Asheesh_Laroia page would form the subject of both the 
public Property:Email and the private Property:telephone, so both 
properties have to be specified on the same page.  So how are you going 
to have a partly-private page in MediaWiki?  Are you thinking of having 
a separate private details page that is somehow tied in with the public 
page?  That makes querying much harder.  Maybe you could have a separate 
namespace for Confidential:Asheesh_Laroia and modify SMW to look up in 
that as well if the user is an admin.

I'm mostly speculating, hope this helps,
--
=S Page

On Thu, 25 Oct 2007, S Page wrote:

> Asheesh Laroia wrote:
>> Is it possible to hide some attributes so that only admins can see 
>> them?
>
> From what I know of the code, not easily.  When a page is saved, SMW 
> parses its annotations and stores the semantic annotations in tables. 
> There's a smw_attributes table with the page ID, the property name, and 
> its value.  No access control at the database level.
>
> Yes, you could add a special property Only_for_admins and modify the SMW code 
> to check this before it does anything with a property.  SMW 1.0 tends to 
> create a DataValue whenever it deals with a property so the change might be 
> well-encapsulated.
>
> HOWEVER,
> Normally the User:Asheesh_Laroia page would form the subject of both the 
> public Property:Email and the private Property:telephone, so both properties 
> have to be specified on the same page.  So how are you going to have a 
> partly-private page in MediaWiki?  Are you thinking of having a separate 
> private details page that is somehow tied in with the public page?  That 
> makes querying much harder.  Maybe you could have a separate namespace for 
> Confidential:Asheesh_Laroia and modify SMW to look up in that as well if the 
> user is an admin.

I guess another total hack is to name all the private properties similarly 
and therefore detectably - and then at render time, if the user is an 
admin, print those, and if the user is not, don't.

What do you [guys] make of that approach?

Thanks for the quick and thoughtful reply!

-- Asheesh.

--
Humans are communications junkies.  We just can't get enough.
 		-- Alan Kay

> I guess another total hack is to name all the private properties similarly
> and therefore detectably - and then at render time, if the user is an
> admin, print those, and if the user is not, don't.

Assuming you had a way to programmatically determine whether the user
has privs to see the info, the next problem to address is caching.
MediaWiki caches the rendered versions of pages to save processing
from visitor to visitor.

-- Jim R. Wilson (jimbojw)

On 10/25/07, Asheesh Laroia <asheesh@...> wrote:
> On Thu, 25 Oct 2007, S Page wrote:
>
> > Asheesh Laroia wrote:
> >> Is it possible to hide some attributes so that only admins can see
> >> them?
> >
> > From what I know of the code, not easily.  When a page is saved, SMW
> > parses its annotations and stores the semantic annotations in tables.
> > There's a smw_attributes table with the page ID, the property name, and
> > its value.  No access control at the database level.
> >
> > Yes, you could add a special property Only_for_admins and modify the SMW code
> > to check this before it does anything with a property.  SMW 1.0 tends to
> > create a DataValue whenever it deals with a property so the change might be
> > well-encapsulated.
> >
> > HOWEVER,
> > Normally the User:Asheesh_Laroia page would form the subject of both the
> > public Property:Email and the private Property:telephone, so both properties
> > have to be specified on the same page.  So how are you going to have a
> > partly-private page in MediaWiki?  Are you thinking of having a separate
> > private details page that is somehow tied in with the public page?  That
> > makes querying much harder.  Maybe you could have a separate namespace for
> > Confidential:Asheesh_Laroia and modify SMW to look up in that as well if the
> > user is an admin.
>
> I guess another total hack is to name all the private properties similarly
> and therefore detectably - and then at render time, if the user is an
> admin, print those, and if the user is not, don't.
>
> What do you [guys] make of that approach?
>
> Thanks for the quick and thoughtful reply!
>
> -- Asheesh.
>
> --
> Humans are communications junkies.  We just can't get enough.
>                 -- Alan Kay
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>

On Thu, 25 Oct 2007, Jim Wilson wrote:

>> I guess another total hack is to name all the private properties 
>> similarly and therefore detectably - and then at render time, if the 
>> user is an admin, print those, and if the user is not, don't.
>
> Assuming you had a way to programmatically determine whether the user 
> has privs to see the info

I think that the logged-in user object has an easy way to tell if it's an 
admin or not, and that should be enough for me; it doesn't have to be 
fine-grained ACLs.

> , the next problem to address is caching. MediaWiki caches the rendered 
> versions of pages to save processing from visitor to visitor.

That's just the parser cache, right?  Perhaps what I'll do is, if the user 
has extra privileges, ignore the parser cache; and for everyone else, 
cache and display the low-privileges rendered version.

If that's not feasible I can probably afford to just disable the parser 
cache as a whole.

-- Asheesh.

--
When a man knows he is to be hanged in a fortnight, it concentrates his
mind wonderfully.
 		-- Samuel Johnson

Although I also wished there would be an easy solution to let only specific user
groups view certain parts of a page there doesn't seem to exist an extention or
other solution which addresses all the related problems according to
http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions

Even if there would be a way to hide certain SMW properties in the factbox (as
its easy to hide them on the page itself) I don't see a straightforward method
to hide these data in the page source when the page is edited. Hidding all
factboxes via $smwgShowFactbox and restricting editing to admins on those pages
doesn't seem very desirable.  

Gu 

Quoting Jim Wilson <wilson.jim.r@...>:

> > I guess another total hack is to name all the private properties similarly
> > and therefore detectably - and then at render time, if the user is an
> > admin, print those, and if the user is not, don't.
> 
> Assuming you had a way to programmatically determine whether the user
> has privs to see the info, the next problem to address is caching.
> MediaWiki caches the rendered versions of pages to save processing
> from visitor to visitor.
> 
> -- Jim R. Wilson (jimbojw)
> 
> On 10/25/07, Asheesh Laroia <asheesh@...> wrote:
> > On Thu, 25 Oct 2007, S Page wrote:
> >
> > > Asheesh Laroia wrote:
> > >> Is it possible to hide some attributes so that only admins can see
> > >> them?
> > >
> > > From what I know of the code, not easily.  When a page is saved, SMW
> > > parses its annotations and stores the semantic annotations in tables.
> > > There's a smw_attributes table with the page ID, the property name, and
> > > its value.  No access control at the database level.
> > >
> > > Yes, you could add a special property Only_for_admins and modify the SMW
> code
> > > to check this before it does anything with a property.  SMW 1.0 tends to
> > > create a DataValue whenever it deals with a property so the change might
> be
> > > well-encapsulated.
> > >
> > > HOWEVER,
> > > Normally the User:Asheesh_Laroia page would form the subject of both the
> > > public Property:Email and the private Property:telephone, so both
> properties
> > > have to be specified on the same page.  So how are you going to have a
> > > partly-private page in MediaWiki?  Are you thinking of having a separate
> > > private details page that is somehow tied in with the public page?  That
> > > makes querying much harder.  Maybe you could have a separate namespace
> for
> > > Confidential:Asheesh_Laroia and modify SMW to look up in that as well if
> the
> > > user is an admin.
> >
> > I guess another total hack is to name all the private properties similarly
> > and therefore detectably - and then at render time, if the user is an
> > admin, print those, and if the user is not, don't.
> >
> > What do you [guys] make of that approach?
> >
> > Thanks for the quick and thoughtful reply!
> >
> > -- Asheesh.
> >
> > --
> > Humans are communications junkies.  We just can't get enough.
> >                 -- Alan Kay
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@...
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>

On Samstag, 20. Oktober 2007, Dan Thomas wrote:
> Will SMW1.0 support dates prior to 1901?  V0.7 displays similar in fact b=
ox
> for such dates:
>
>
> [Oops! The date "1889/10/6" was not understood. Support for dates is still
> experimental.]

No, not yet. This is planned for the next release after 1.0. The problem is=
=20
that all our input functions, and all the MediaWiki output functions, are=20
restricted to this range. Also, the database layout we currently use must b=
e=20
modified to store more times. When we do it, however, we plan to do it=20
properly: arbitrary dates within the expected lifetime of the universe,=20
precise to seconds, with internationalised input parsing, and some support=
=20
for imprecision (i.e. "2007" is not necessarily the same as "Jan 1 2007=20
00:00").=20

Markus

=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
mak@...        www  http://korrekt.org

I didn't test RC1. but I noticed that dates are not sorted correctly within
inline queries. Is it fixed in 1.0?

      Sergey


On 10/21/07, Markus Kr=F6tzsch <mak@...> wrote:
>
> On Samstag, 20. Oktober 2007, Dan Thomas wrote:
> > Will SMW1.0 support dates prior to 1901?  V0.7 displays similar in fact
> box
> > for such dates:
> >
> >
> > [Oops! The date "1889/10/6" was not understood. Support for dates is
> still
> > experimental.]
>
> No, not yet. This is planned for the next release after 1.0. The problem
> is
> that all our input functions, and all the MediaWiki output functions, are
> restricted to this range. Also, the database layout we currently use must
> be
> modified to store more times. When we do it, however, we plan to do it
> properly: arbitrary dates within the expected lifetime of the universe,
> precise to seconds, with internationalised input parsing, and some suppor=
t
> for imprecision (i.e. "2007" is not necessarily the same as "Jan 1 2007
> 00:00").
>
> Markus
>
> --
> Markus Kr=F6tzsch
> Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
> phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
> mak@...        www  http://korrekt.org
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>

On Sonntag, 21. Oktober 2007, Sergey Chernyshev wrote:
> I didn't test RC1. but I noticed that dates are not sorted correctly with=
in
> inline queries. Is it fixed in 1.0?

That should have been a temporary problem in some SVN versions before RC1. =
It=20
should be fixed now.

Markus

>
>       Sergey
>
> On 10/21/07, Markus Kr=F6tzsch <mak@...> wrote:
> > On Samstag, 20. Oktober 2007, Dan Thomas wrote:
> > > Will SMW1.0 support dates prior to 1901?  V0.7 displays similar in fa=
ct
> >
> > box
> >
> > > for such dates:
> > >
> > >
> > > [Oops! The date "1889/10/6" was not understood. Support for dates is
> >
> > still
> >
> > > experimental.]
> >
> > No, not yet. This is planned for the next release after 1.0. The problem
> > is
> > that all our input functions, and all the MediaWiki output functions, a=
re
> > restricted to this range. Also, the database layout we currently use mu=
st
> > be
> > modified to store more times. When we do it, however, we plan to do it
> > properly: arbitrary dates within the expected lifetime of the universe,
> > precise to seconds, with internationalised input parsing, and some
> > support for imprecision (i.e. "2007" is not necessarily the same as "Jan
> > 1 2007 00:00").
> >
> > Markus
> >
> > --
> > Markus Kr=F6tzsch
> > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
> > phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
> > mak@...        www  http://korrekt.org
> >
> > -----------------------------------------------------------------------=
=2D-
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@...
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
mak@...        www  http://korrekt.org

Sorry, my first main missed the list again:

Yes, I think that's in the plans (although Markus didn't reply to my email
about it on the list).


On 10/17/07, Luka Frelih <luka@...> wrote:
>
> hello!
> > Yaron and I observed a problem with template parameters handling
> > within <ask> queries in SMW 1.0 RC1.
> > Basically they don't get expanded.
> > I've created a bug in MediaZilla for that:
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=11684
> > Same problem exists within template rendering when template is used as
> > format for querying. Luka's patch doesn't help with it.
> i think a simple way to get this functionality would be to implement an
> ask function. as functions get parsed later than the tags, template
> parameters and functions within it would get expanded before the call.
>
> if i'm not mistaken someone has already done some work towards that.
>
> LF
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>



-- 
Sergey Chernyshev
http://www.sergeychernyshev.com/

What's funny about this (to me), is that I actually took the time to
develop such a parser function, created a patch and submitted it to
bugzilla[1].

Needless to say it was never incorporated because of a pending
"rewrite" of some core functionality.  So I created an extension to do
this as well[2].

I haven't tested the extension against any other version of SMW than
what I originally targeted, so it may no longr work. I believe I
developed against 0.7.

[1] http://bugzilla.wikimedia.org/show_bug.cgi?id=10021
[2] http://jimbojw.com/wiki/index.php?title=SMW_InlineQueryParserFunction_Extension

Good luck!

-- Jim R. Wilson (jimbojw)

On 10/17/07, Sergey Chernyshev
<semediawiki-devel@...> wrote:
> Sorry, my first main missed the list again:
>
> Yes, I think that's in the plans (although Markus didn't reply to my email
> about it on the list).
>
>
>
> On 10/17/07, Luka Frelih <luka@...> wrote:
> > hello!
> > > Yaron and I observed a problem with template parameters handling
> > > within <ask> queries in SMW 1.0 RC1.
> > > Basically they don't get expanded.
> > > I've created a bug in MediaZilla for that:
> > > http://bugzilla.wikimedia.org/show_bug.cgi?id=11684
> > > Same problem exists within template rendering when template is used as
> > > format for querying. Luka's patch doesn't help with it.
> > i think a simple way to get this functionality would be to implement an
> > ask function. as functions get parsed later than the tags, template
> > parameters and functions within it would get expanded before the call.
> >
> > if i'm not mistaken someone has already done some work towards that.
> >
> > LF
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@...
> >
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> >
>
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>

Jim, nobody undermines your effort - thank you for both patch and extension,
great work!
I believe we all (including Markus and co) just wait when it'll get to the
top of the priority list.

P.S. Sorry, I sent it to the list from wrong address again. This antispam
filter will kill me...

On 10/17/07, Jim Wilson <wilson.jim.r@...> wrote:
>
> What's funny about this (to me), is that I actually took the time to
> develop such a parser function, created a patch and submitted it to
> bugzilla[1].
>
> Needless to say it was never incorporated because of a pending
> "rewrite" of some core functionality.  So I created an extension to do
> this as well[2].
>
> I haven't tested the extension against any other version of SMW than
> what I originally targeted, so it may no longr work. I believe I
> developed against 0.7.
>
> [1] http://bugzilla.wikimedia.org/show_bug.cgi?id=10021
> [2]
> http://jimbojw.com/wiki/index.php?title=SMW_InlineQueryParserFunction_Extension
>
> Good luck!
>
> -- Jim R. Wilson (jimbojw)
>
> On 10/17/07, Sergey Chernyshev
> <semediawiki-devel@...> wrote:
> > Sorry, my first main missed the list again:
> >
> > Yes, I think that's in the plans (although Markus didn't reply to my
> email
> > about it on the list).
> >
> >
> >
> > On 10/17/07, Luka Frelih <luka@...> wrote:
> > > hello!
> > > > Yaron and I observed a problem with template parameters handling
> > > > within <ask> queries in SMW 1.0 RC1.
> > > > Basically they don't get expanded.
> > > > I've created a bug in MediaZilla for that:
> > > > http://bugzilla.wikimedia.org/show_bug.cgi?id=11684
> > > > Same problem exists within template rendering when template is used
> as
> > > > format for querying. Luka's patch doesn't help with it.
> > > i think a simple way to get this functionality would be to implement
> an
> > > ask function. as functions get parsed later than the tags, template
> > > parameters and functions within it would get expanded before the call.
> > >
> > > if i'm not mistaken someone has already done some work towards that.
> > >
> > > LF
> > >
> > >
> > >
> >
> -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc.
> > > Still grepping through log files to find problems?  Stop.
> > > Now Search log events and configuration files using AJAX and a
> browser.
> > > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > > _______________________________________________
> > > Semediawiki-devel mailing list
> > > Semediawiki-devel@...
> > >
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> > >
> >
> >
> >
> > --
> > Sergey Chernyshev
> > http://www.sergeychernyshev.com/
>

On Mittwoch, 17. Oktober 2007, Sergey Chernyshev wrote:
> Jim, nobody undermines your effort - thank you for both patch and
> extension, great work!
> I believe we all (including Markus and co) just wait when it'll get to the
> top of the priority list.

Yes, Sergey is absolutely right. The "rewrite" has indeed be very extensive=
=20
and changed about everything that is done to execute inline queries. It was=
=20
just impossible to interleave this with a switch from HTML output to wiki=20
output. {{ask}} parserfunctions are vital to solve the problems raised=20
earlier in this thread (note that there already are MW bugs filed because o=
f=20
the template-parameter issue), and we will start with your patch to find ou=
t=20
how to make this work.

So please be patient -- we have not released any stable version of SMW sinc=
e=20
you submitted your patch.

Best regards,

Markus

>
> P.S. Sorry, I sent it to the list from wrong address again. This antispam
> filter will kill me...

Yes, it's a pitty that anti-spam measures need to be so violent these days =
:-(

>
> On 10/17/07, Jim Wilson <wilson.jim.r@...> wrote:
> > What's funny about this (to me), is that I actually took the time to
> > develop such a parser function, created a patch and submitted it to
> > bugzilla[1].
> >
> > Needless to say it was never incorporated because of a pending
> > "rewrite" of some core functionality.  So I created an extension to do
> > this as well[2].
> >
> > I haven't tested the extension against any other version of SMW than
> > what I originally targeted, so it may no longr work. I believe I
> > developed against 0.7.
> >
> > [1] http://bugzilla.wikimedia.org/show_bug.cgi?id=3D10021
> > [2]
> > http://jimbojw.com/wiki/index.php?title=3DSMW_InlineQueryParserFunction=
_Ext
> >ension
> >
> > Good luck!
> >
> > -- Jim R. Wilson (jimbojw)
> >
> > On 10/17/07, Sergey Chernyshev
> >
> > <semediawiki-devel@...> wrote:
> > > Sorry, my first main missed the list again:
> > >
> > > Yes, I think that's in the plans (although Markus didn't reply to my
> >
> > email
> >
> > > about it on the list).
> > >
> > > On 10/17/07, Luka Frelih <luka@...> wrote:
> > > > hello!
> > > >
> > > > > Yaron and I observed a problem with template parameters handling
> > > > > within <ask> queries in SMW 1.0 RC1.
> > > > > Basically they don't get expanded.
> > > > > I've created a bug in MediaZilla for that:
> > > > > http://bugzilla.wikimedia.org/show_bug.cgi?id=3D11684
> > > > > Same problem exists within template rendering when template is us=
ed
> >
> > as
> >
> > > > > format for querying. Luka's patch doesn't help with it.
> > > >
> > > > i think a simple way to get this functionality would be to implement
> >
> > an
> >
> > > > ask function. as functions get parsed later than the tags, template
> > > > parameters and functions within it would get expanded before the
> > > > call.
> > > >
> > > > if i'm not mistaken someone has already done some work towards that.
> > > >
> > > > LF
> >
> > -----------------------------------------------------------------------=
=2D-
> >
> > > > This SF.net email is sponsored by: Splunk Inc.
> > > > Still grepping through log files to find problems?  Stop.
> > > > Now Search log events and configuration files using AJAX and a
> >
> > browser.
> >
> > > > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > > > _______________________________________________
> > > > Semediawiki-devel mailing list
> > > > Semediawiki-devel@...
> > >
> > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
> > >
> > >
> > >
> > >
> > > --
> > > Sergey Chernyshev
> > > http://www.sergeychernyshev.com/



=2D-=20
Markus Kr=F6tzsch
Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362        fax +49 (0)721 608 5998
mak@...        www  http://korrekt.org

> So please be patient -- we have not released any stable version of SMW since
> you submitted your patch.
There are so many great possibilities of templates together with ask
queries!

It's good for me to hear that it's not just me missing #ask parser
function. Makes the thing important.

But of course it's preferrable to have these with SMW 1.0. Some parts
of querying in SMW 0.7 were buggy. Also, 1.0 seems to have more
features in general.

I'm trying to be patient.. Let's hope that Jim Wilson effort will
speed up the development.

Dmitriy