I may have spoke too soon the other night.  While setting the Influcenced property with the ask query seemed to work, it actually concatenated multiple property values by a comma into a single value.

When I look at the value through the Fact Box, Influenced = Philosopher1,Philosopher2 (both of these being a single value). 

Any ideas?

On Mon, Sep 21, 2009 at 12:13 AM, Eric T. Blue <ericblue76@gmail.com> wrote:
Laurent and Temlakos,

Thank you both for your quick reply and suggestions!  I still need to wrap my head around some of the syntax and options, but I believe I may have the beginning of a solution.  For right now I decided to reduce the number of variables while trying to make this work, so I eliminated templates and worrying about the result output of the relationships.

I basically defined both the Influences and Influenced properties directly on the page itself.  Influences values were statically defined (1 or more) using the set syntax:


And, the Influenced property was set using a dynamic query:


For reasons I don't yet understand, if I exclude the link=none setting, the property does NOT get set at all.  In order to verify that this worked OK, I simply re-enabled the FactBox and confirmed the properties were set as expected.  Although the syntax is a little verbose, I'm sure I can work this back into a template and try the more sophisticated inverse property template.  And, If I want I could do another ask to display the output for both properties in the same format.  For example:

{{#ask: [[Category:Philosopher]] [[Name::Philosopher1]]
| ?Influenced
| mainlabel=-
| format=broadtable

From what you described, it sounds like the auto-inversing feature will be quite handy.  I'll look forward to trying that out when it becomes available.  In the meantime, I'll continue to refine this solution based on your suggestions and re-work it back into a template.

Thanks for your help!

On Sun, Sep 20, 2009 at 6:16 PM, Temlakos <temlakos@gmail.com> wrote:
If your model assumes that one philosopher may influence one or more others, then the property of "Influences" ought to be of type Page, not String. A String property creates no links. A Page property sets up an internal Wiki link, same as double square brackets without a semantic annotation operation.

Concerning multiple values: What you do in that case is simply annotate every philosopher on whom your index case had an influence. Any property, particularly of type Page, may have multiple values annotated in any one article. I do it all the time, to annotate sons, daughters, brothers, or sisters, for example.

Markus' new automatic inversing code will shortly make the explicit creation of inverse properties unnecessary. You would simply query the "inverse of Influences" to determine every philosopher who had an influence on the index case.

As it happened, I copied a template called "Template:Invert-property" that would automatically assign inverse-property annotations as appropriate. So instead of attempting a dynamic query, I essentially made a dynamic annotation of inverse properties. The inventor of this code was User:DanTMan on the SMW wiki. Here is the code:


Where Template:Invert-property/Separator does this:

| ]][[{{{1}}}::

I strongly suspect that the key to making this code work without a segmentation fault is the parameter assignment "link=none." The "limit=250" limits you to 250 inverse-property assignments. This code has worked on my wiki without a problem.

To call it in one of your pages, you would call {{Invert-property|Influences|Influenced}} once on your page, and it would make the annotation assignments silently.

But now that every Page property will automatically have its inverse defined and queryable, I deprecate that solution and suggest installing the new auto-inversing system as soon as it becomes available in a beta release. Last I heard, Markus had checked that auto-inversing code into the Subversion repository. (How about that, Markus? How can one install a version of SMW with auto-inversing today, and how soon will one be able to install it in a tarball release?)


Eric T. Blue wrote:

I'm been using SMW as a knowledge management tool for a number of things, and have recently started looking into using it as a research aid for historical figures, philosophers, writers, etc.  Up until now, I've been storing fairly simple properties for most types of people (e.g. Philosopher has a BirthDate, BirthPlace, SchoolorTradition, etc.).  However, I want to take it a step further and model relationships between people.  In particular, I want to model who influenced that person and in turn who they influenced.  This type of modeling seems pretty common at DBPedia and Freebase.  Ultimately, I want to browse this data in a faceted viewer like Exhibit or create some visualation engine to navigate (for example, Genaology of Influence - http://goosebumps4all.net/goi/).

Are there any best practices for modeling this type of directional/many-many relationship?  I was considering taking the following approach, but am not sure if it's practical or technically feasible:

 1) Create an infobox template for type the type of person/category (say Philosopher) and create a property of Influences
  ! [[Property:Influences | Influences]]
| [[Influences::{{{Influences}}}]]

Questions: Should this Property type be a String?  And, how do you define multiple values?

2) Create a property for who the Philosopher influenced

If I add a new person, I obviously don't want to have to be creating static property values all over the place.  So, I thought this could be dynamically set.

! [[Property:Influenced | Influenced]]
| {{#ask:
 | limit = 3

Questions: This does not appear to work at all.. in fact, it is causing segfaults :) Should I be able to dynamically set a property with an inline query?

Assuming my serious problem is solved by syntax changes, does this overall approach seem viable?  Or, am I going about this the hard way?


Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;

Semediawiki-user mailing list