A page can have more than one property, and a property can be another page that has properties of its own. Properties can form a complex web (connected graph). The best-practice is for properties to point from child to parent, so the graph ends up looking more like a tree than a web. That best-practice reduces the complexity somewhat, and is worth mentioning, even though it isn't exactly on the point of what I'd like to say here. Also, it is important to note that "properties" are almost synonymous with "pages", because they're basically a special type of page.
Querying properties is the basic functionality of any semantic system. Right now, there is no simple or reliable way to obtain a the value of a property that is not directly connected to the property/page where the query originates. For example, for these properties A -> B -> C A cannot easily access C, and vice versa, but B can access everything (A, B, and C). If we add D, like this: A -> B -> C -> D Then, the semantic interconnection of properties is broken, because there's nothing that can access everything. There's a somewhat complicated workaround here, that seems to be describing the "ABC chain of three" in the first example: http://smw.referata.com/wiki/Query_linked_properties It could probably work with any number of linked properties, with increasing complexity - EXCEPT, it's a hack that doesn't work with properties/pages that have commas in them. That means Semantic Maps can't get geographic locations, and nothing that has multiple comma-separated values for a property can work. This has the unfortunate consequence of rendering useless the best practice of pointing properties from child to parent. Not only that, but since the chain of properties can't be navigated, pages cannot inherit properties. This means that each page must have all the inheritable properties in its graph explicitly defined. This scales exponentially! And, it is a nightmare to update things that change. There are other workarounds involving Semantic Internal Objects: http://www.mediawiki.org/wiki/Extension_talk:Semantic_Internal_Objects#Combining_regular_semantic_queries_with_SIO.3F And multiple queries within templates: http://semantic-mediawiki.org/wiki/Help:Selecting_pages#Subqueries_for_properties But obviously, it would make a semantic wiki much more useful if such complex hacks could be replaced with just a simple query. It could even be transparent. For example, let's say you have these relationships: Object -> Owner -> Location Object -> Type The two graphs are linked together via the object, because an object has both an owner and a type (of object). The owner has a location, and the object's location is the same as the owner's location. If I want to run a query showing the location of all objects of a particular type, I would be starting from the type and trying to query through to the location. The actual relationship is like this: Type <- Object -> Owner -> Location But a simple query could look like this: Type -> Object -> Owner -> Location I need to get to the owner, then to the owner's location. So, why not make it easy, like this: {{#ask: [[Type]] | ?Location}} Which could traverse the inheritance graph beginning from the type, until it finds the location property. Once this query is cached, hopefully it will not be any more expensive than any other query. If it's still problematic, then the query could be more explicit about where to find the information: {{#ask: [[Type]] -> [[Object]] -> [[Owner]] | ?Location}} Or, if the query is already understood to be beginning with the type, it could look like this: {{#ask: [[Object]] -> [[Owner]] | ?Location}} We could even simplify the syntax like this: {{#ask: [[Object]] -> [[Owner]] -> [[Location]]}} And, we can make it easy to get multiple properties, such as the location, name, and height of the object owner, like this: {{#ask: [[Object]] -> [[Owner]] -> [[Location]], [[Name]], [[Height]]}} Maybe could get any properties along the way, with one explicit query syntax, like this: {{#ask: [[Type]] -> [[Object]]: [[Color]], [[Size]] -> [[Owner]]: [[Location]], [[Name]], [[Height]]}} To make it more readable: {{#ask: [[Type]] -> [[Object]]: [[Color]], [[Size]] -> [[Owner]]: [[Location]], [[Name]], [[Height]] }} Above, colons take the place of where a pipe and a question mark would normally be. If we want to go with that syntax instead, the last most-detailed query would look like this: {{#ask: [[Type]] -> [[Object]] | ?Color, ?Size -> [[Owner]] | ?Location, ?Name, ?Height }} Or maybe like this: {{#ask: [[Type]] -> [[Object]] | ?Color | ?Size | -> [[Owner]] | ?Location | ?Name | ?Height }} The above would return object colors, sizes, owner location, owner name, and owner height. But that's fantasy. It actually works a quite differently right now, due to very limited ability of Semantic Mediawiki to traverse property chains. Within a template, nested #show can traverse forward through the property chain. The initial #ask traverses one step backwards through the property chain. For example, starting from Type, we go backward one step, and then forward 2 steps from Object through Owner to get to Location: Object -> Owner -> Location Object -> Type Or represented another way: Type <- Object -> Owner -> Location We use an #ask on the Type page to move 1 step in reverse to find the objects: {{#ask: [[Category:Objects]] [[Type::{{PAGENAME}}]] | ? | format=template | template=Type object locations | introtemplate=Table start | outrotemplate=Table end | link=none }} Then the template "Type object locations" uses nested #show to move 2 steps forward to reach the Location: {{#show: {{#show: {{{1}}} | ?Belongs to | link=none}} | ?Location}} Wouldn't it be so much easier to keep track of what's going on if all you had to do is this?: {{#ask: [[Type]] -> [[Object]] -> [[Owner]] | ?Location}} What we're dealing with is basically just a linked list: http://en.wikipedia.org/wiki/Linked_list Is this data structure being dealt with as a linked list within SMW's code? If not, could it be? If it could, should it be? Singly linked lists still have the problem of traversing the list backwards that we currently have. But, a doubly linked list could solve that issue, so long as the lack of persistence is dealt with by changing SMW's internal representation of the "back link" when changes are made by the user to the forward link. For example, the user would see this: A <- B -> C -> D But SMW would ALSO have an internal map that looks like this: A <-> B <-> C <-> D That would have to be updated internally if the user changes this: A <- B -> C -> D To this: B -> A -> C -> D Is this something that could be handled without causing performance problems? -- View this message in context: http://old.nabble.com/Querying-simple-interconnected-properties-tp32276990p32276990.html Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
