On 10/02/2011 19:01, Yury Katkov wrote: > 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.
Right, you can hide link-style annotations as well, but #set has mainly been introduced to make it easier to add "hidden" annotations at the end of pages. It is also nicer from a conceptual point of view since it avoids many hassles that parsing link syntax brings. But it was not meant to behave differently upon transclusion. - Markus > > On Thu, Feb 10, 2011 at 7:04 PM, Markus Krötzsch > <mar...@semantic-mediawiki.org <mailto: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 > <mailto: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
