While Ask is a good query language for most things in SMW. It is not as robust as SPARQL, which I use for nearly all of my queries.
You can find the SPARQL standard at [1] SMW 1.6 have much better support for SPARQL and associated triple stores - more info at [2] [1] http://www.w3.org/TR/sparql11-query/ [2] http://semantic-mediawiki.org/wiki/Help:Using_SPARQL_and_RDF_stores > -----Original Message----- > From: badon [mailto:fastgoldf...@gmail.com] > Sent: Wednesday, August 17, 2011 12:35 AM > To: semediawiki-devel@lists.sourceforge.net > Subject: [SMW-devel] Querying simple interconnected properties > > > 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 ------------------------------------------------------------------------------ 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
