Relations and Transitivity
- If property P is a subproperty of property P', then all pairs of resources which are related by P are also related by P'.
Since querying for P' doesn't actually show the relationships stated by P, is it really accurate to say that this property agrees with the statement?
Following the example, if I have "husband" and "wife" as subproperties of "spouse", and I give the page "Ann" a "husband" relation to the page "Frank", there doesn't actually seem to be a "spouse" relationship created. If I ask who Ann's husband is, "Frank" is returned. But if I ask the name of her spouse, nothing is returned. More bizarrely, if I ask for articles with the spouse property set, and ask them what their spouse properties are set to... I get nothing!
Perhaps I'm misunderstanding this, but it seems like a tremendous asymmetry in functionality. This could be very useful, but it seems crippled.
- Kalisphoenix 22:24, 9 May 2012 (CEST)
In the notes, I've explained what those comments (which were written by someone else) mean in practice, i.e. when you build a query. You can find Ann’s "spouse" by querying on the spouse property (e.g. "Is spouse of"), but in order to get results you’ll have to include the relevant subproperties (e.g. "Is wife of", not "Is spouse of") in the printout statement.
Yeah, that's what I'm complaining about :D
Let's say I'm trying to output Ann's spouse's name, say, in an infobox. My query looks like this: {{#show:Ann|?{{#ifeq:{{#show:Ann|?Gender}}|Male|Wife|Husband}}|}} or (if we're being refreshingly modern) {{#show:Ann|?{{#if:{{#show:Ann|?Husband}}|Husband|Wife|}}|}}
Now, IMHO, the name of Ann's husband or wife should be revealed by {{#show:Ann|?Spouse}}. Ann's husband is Frank. If Frank is Ann's husband, Frank is Ann's spouse. Who is Ann's spouse? Semantic MediaWiki claims not to know.
Similarly, if I'm displaying a table, I don't feel like I should have to devote two columns to subproperties of Spouse. If I have a Relative property that has as subproperties Mother, Father, Son, Daughter, Brother, Sister, Aunt, Uncle, Stepmother, Stepfather, Stepson, Stepdaughter, and on and on and on into infinity, I hopefully wouldn't need 47 columns in my table, most of which would be empty.
So I feel as though it's an issue with usability. Perhaps some (even most) prefer it the way that it is, or perhaps it's a feature that's not frequently utilized and most people don't care. But I feel as though if you're going to express it in logical terms, you should adhere to those terms. If the relation exists, it exists and should be displayed when queried.
Here's the real issue, though: it's dumb. It doesn't serve any purpose. Here:
{{#ask: [["head property"::+]]
|? "head property"
|? "subproperty1"
|? "subproperty2"
}}
- Why even create this special property if all it's "saving" you from doing is this:
{{#ask: [["subproperty1"::+]] OR [["subproperty2"::+]]
|? "subproperty1"
|? "subproperty2"
}}
In fact, the second version's better anyway because it doesn't have a stupid extra empty column. And a stupid extra property.
Kalisphoenix 06:23, 25 May 2012 (CEST)
+1. Why? Is it a matter of principle or fundamental flaw in SMW architecture? Is there any hope that it ever change?
Alexander Mashintalk 14:18, 4 January 2013 (CET)
+1. What Kalisphoenix describes is exactly how I expected subproperties to work: if I #ask a query to return ?Spouse, then it should return any values assigned to Spouse or its subproperties. As it is, this seems like a fairly useless feature.
Dr ishmael (talk) 06:19, 18 April 2013 (CEST)
If, however, your annotation has <Frank "is husband of" Ann>, but not the other way around (<Ann "is wife of" Frank>), then it’s a matter of Inverse properties and the general issue that SMW properties point in one direction.
Cavila 13:09, 10 May 2012 (CEST)
What has happened to the messages above? The placement of names and dates has gone awry for some reason. Is it a bug in LiquidThreads?
Everything works as expected. The second date is the date I transformed regular talk into LQT talk on this page. I preserved the original dates within the signature. Cheers
Ah that explains. That and the fact that in the pre-LQT version, the first part of my post got separated from the second part when another user replied in the middle of it (hence the current lack of a signature). I was just worried that LQT did something off.
