Markus,
Thank you very much for the clarifications and thoughtful explanations
(and the link to the bug report). As you requested, I've made the
changes to the talk pages to reflect the fact that the {{#set:}}
inheritance behavior is a bug, not a feature.
After conducting some further testing, I saw the inheritance issue again
with some [[property::value]] relationships and queries when
SMW_QueryPrinter's maxRecursionDepth is set to > 2 (in fairness,
SMW_QueryPrinter specifically warns about some "risk" of increasing that
value - this may be that risk), but there is a relatively simple patch
that I developed to address this. Bug report, steps to reproduce, and
patch coming to bugzilla in the next few days if I can reliably
reproduce the issue; one attempt is here:
http://sandbox.semantic-mediawiki.org/wiki/Embed123 -- incidentally,
that page also demonstrates how to (messily) circumvent
maxRecursionDepth, which may be something else to look into (or not;
this could be expected).
As for {{#set:}}, another user reminded me off-list that although it is
easy to enclose {{#set}} in <noinclude> tags on ordinary pages, it can
be difficult to prevent unwanted propagation of {{#set:}} values when
setting them with templates (or forms) because there is not a currently
known way to place <noinclude> tags around values one wishes to retain
in templates but still use the template. This could make it difficult to
use the #set function to its full potential (potentially even moreso its
cousin, #set_internal).
In the meantime, until a longer-term solution can be found to make
{{#set:}} behave more like [[property::value]] in terms of behavior when
embedded, here is a question for you and/or the list:
Are you aware of a way to automatically wrap {{#set:}}-like functions in
<noinclude> tags behind the scenes (or perhaps do the equivalent via
some template, magic word, or extension) after parsing of the rest of
the page's content, e.g., when {{#set:}} appears on pages embedded by
queries so that {{#set:}} can be used in templates/forms without risk of
unwanted property propagation? I don't think that I can competently and
timely address this, but might something like that be worth exploring as
an interim solution? (There are some workarounds I can think of, but
they generally require external software, e.g., pywikipediabot, and/or
lots of maintenance work - I'm also currently fiddling with the
RegexFunctions extension to see if that can be made to work on query
output).
As for a data modeling strategy, I certainly see your point about the
dangers of intentionally setting properties by embedding properties from
other pages, but I can imagine some rare--and now, after reading your
message, perhaps extremely rare--instances where it might be useful.
That said, based on your clarifications, I will certainly not plan on
using {{#set:}} to make properties get inherited via embed queries.
Thanks again for the clarifications, and an even bigger thank you and
your team for this amazing software: I have been a very happy user since
2006.
-Alex
--
ontolawgy™ LLC: connect . . . the . . . dots™
http://ontolawgy.com
----Original Message-----
To: Markus Krötzsch <mar...@semantic-mediawiki.org>
Cc: Alex M. Hendler <amh.pub...@ontolawgy.com>, SMW developer list
<semediawiki-devel@lists.sourceforge.net>
Subject: Re: [SMW-devel] Thank you for recent(?) changes to property
handling for recursive/embedded queries
Date: Thu, 10 Feb 2011 16:04:49 +0000
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
