From: badon <fas...@gm...> - 2011-08-17 04:34:46
|
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. |
From: Smith, T. <smi...@pg...> - 2011-08-17 13:34:29
|
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:fas...@gm...] > Sent: Wednesday, August 17, 2011 12:35 AM > To: sem...@li... > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: badon <fas...@gm...> - 2011-08-17 22:50:58
|
Fascinating information. I have enjoyed reading about this technology, though it looks like I'm not able to use it in my system yet. I can't find a SPARQL DB engine like 4store that works out-of-the-box on a ZFS data-integrity-conscious operating system. Still, this line of development progress does seem to be capable of addressing most of the questions I had. Maybe in the future there will be an interesting way of getting this to work without needing new software on the OS (or a new, compatible OS). Do you have an URL where I can see working examples of SPARQL queries? Smith, Tim-3 wrote: > > 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:fas...@gm...] >> Sent: Wednesday, August 17, 2011 12:35 AM >> To: sem...@li... >> 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 >> Sem...@li... >> 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- View this message in context: http://old.nabble.com/Querying-simple-interconnected-properties-tp32276990p32283722.html Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. |
From: badon <fas...@gm...> - 2011-08-17 22:51:30
|
Fascinating information. I have enjoyed reading about this technology, though it looks like I'm not able to use it in my system yet. I can't find a SPARQL DB engine like 4store that works out-of-the-box on a ZFS data-integrity-conscious operating system. Still, this line of development progress does seem to be capable of addressing most of the questions I had. Maybe in the future there will be an interesting way of getting this to work without needing new software on the OS (or a new, compatible OS). Do you have an URL where I can see working examples of SPARQL queries? Smith, Tim-3 wrote: > > 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:fas...@gm...] >> Sent: Wednesday, August 17, 2011 12:35 AM >> To: sem...@li... >> 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 >> Sem...@li... >> 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- View this message in context: http://old.nabble.com/Querying-simple-interconnected-properties-tp32276990p32283731.html Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. |