On 09/02/2011 19:19, Alex M. Hendler wrote:
> Dear SMW Development Team,
>
> Thank you very much for the recent(?) changes to SMW's behavior
> regarding how properties are treated when a page is transcluded or
> embedded via a query: It offers a great deal of flexibility and allows
> much more granular management of semantic data than was possible in the
> past.
>
> I am not sure when this got introduced, but in my experience, up to
> version 1.5.1 (or .2), pages containing embed queries (or transcluding
> other pages) would still inherit properties from the embedded pages. As
> of 1.5.5.1 (I am not sure whether the change was introduced before
> that), this is no longer the case for ordinary ([[Property::value]])
> properties. This is great news!
It should always have been like this. If not, then some bug might have
been at work on your site.
>
> Also, I have noticed, but I have not seen documented on the SMW site,
> that properties assigned via {{#set:}} (and its related functions) will
> be inherited via embed queries or transclusion. Please do not change
> this, it is a great feature! It provides a great deal of flexibility,
> and now allows something which I (and possibly others?) have wanted to
> do for a long time (I wrote to this list last August about a possible
> feature/option like this): This behavior allows certain properties to be
> "inherited" via transclusion or an embed query, but prevents that
> behavior by default, i.e., for [[property::value]] statements.
This is not intended and is likely to be rectified in future versions.
Clearly, the difference between property-annotation and #set is its
appearance on the page, and it would not be good design to couple this
with difference embedding behaviour (or otherwise, one might at least
want to have all four combinations of behaviours here).
The baheviour you note is merely an accident, that does not lead to the
functionality that you would like to have. The reason is that
"inheriting" annotations through queries is not supported properly by
SMW, since updates are not triggered. If you change the inherited
property value on some page, then this will *not* change the stored
value for the query page that "inherits" it. This is already bad in
other cases where people use "query-generated property values" but it is
even more critical in your scenario, since the page with the embed query
would probably not be edited a lot (since the query is there, the view
"updates itself", at least after some time, without needing editing).
This is very problematic, since the view of the query page will then be
different from the actual data stored by SMW.
I mark your wish for a more configurable behaviour here, but I cannot
promise that this will ever be implemented in a satisfactory fashion,
and I can only urge you to reconsider the way in which you model data in
your wiki (for a deeper reason why SMW does not support this, note that
the automatic propagation of values through query results would be
sufficient to model arbitrary computations in a system of SMW pages --
you do not want this). For now, we will just keep it as it is, but it
should not be documented as the official behaviour (since it is merely a
bug that gives the wrong impression that there is a feature that does
not exist).
To allow at least "one-step" propagation of values (avoiding recursion)
one would still need to first implement a monitoring mechanism that
pushes query updates to pages (this requires a new query management
facility that keeps query statistics in the database). This is some work
already. One could use the existing jobs to trigger the required
database updates when query changes were found (deferred updating, but
the best we can do). Finally, one would need a mechanism to prevent
"inherited" property values to be further propagated to other pages, so
as to avoid infinite recursion. I do not see immediately how this could
be done in a practical way.
>
> I have added a few notes on the talk pages for the "embed" format
> (http://semantic-mediawiki.org/wiki/Help:Embedded_format) and the "set"
> parser function (http://semantic-mediawiki.org/wiki/Help:Setting_values)
> on the SMW main wiki, but you may want to add to the "official"
> documentation that #set: values will get transcluded via an embed format
> query or basic transclusion and that this can be overridden by enclosing
> in<noinclude> tags or simply writing [[Property::value| ]] instead. I
> think that this information could be useful on both pages;
> alternatively, a pointer to the talk pages might help direct people
> towards this information, which I would have found quite helpful as a
> user with limited ability to look through the code to see why this works
> the way it does.
>
> Again, I am very much enjoying the new (to me, at least) flexibility of
> choosing which properties get transcluded and which do not; please let
> that functionality continue to be available for future releases. Thanks!
I am afraid that this functionality is not even really there right now;
it just looks like it is because you *see* the transcluded property
values, even though they are *not stored* until some edit comes along. I
acknowledge your feature request, and I would also like to see this, but
I am not able to provide a satisfactory solution for this in a
foreseeable future (step 1 above -- query management -- is surely a good
thing to have; we have requests about this already).
So I would appreciate if you could update the pages you modified to
reflect the state of affairs.
Thanks,
Markus
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Semediawiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
