It's strange that you say that the difference between property-annotation
and #set is its appearance on the page. I use [[Property_name::value|]]
syntax for that and I always thought that the #set parser function has been
designed to support the kind of behavior Alex mentioned.
On Thu, Feb 10, 2011 at 7:04 PM, Markus Krötzsch <
mar...@semantic-mediawiki.org> wrote:
> Actually, we even already have an open bug report for this problem:
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=26658
>
> - Markus
>
> On 10/02/2011 15:02, Markus Krötzsch wrote:
> > 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
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
--
Yury V. Katkov
Laboratory of intelligent systems
of the Saint-Petersburg National University of Information Technologies,
Mechanics and Optics, Russia
http://ailab.ifmo.ru
------------------------------------------------------------------------------
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
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
