Thank you very much for your reply!
> > (?a isType ?b) (?a hasField ?c) -> (?a hasChild ?c) > Should that be: > (?a isType ?b) (?b hasField ?c) -> (?a hasChild ?c) Yes, sorry about that. > > now I have a tree (possibly recursive as that is allowed) with root as the > > root. > And that graph (a tree with loops is a graph I think) is a graph of > fields, right? Yes. > > So, let me use a concise notation of a/b/c means a hasChild b and b > > hasChild c (as above), I need to be able to query a path for things > > associated with it which should both return everything that is > > attached to c (c ? ?), plus everything that would apply to the a/b/c > > path. > What's the difference between something "attached to c" and something > which "applies to the a/b/c" path? Sorry, I wasn't being precise. But there are two kinds of things that I probably meant: attached to means there are things with a hasChild relationship to that path. applies to would be other properties that apply to it like: hasColor, hasSomething, etc. > > And I need make such statements not just one path at a time, but path > > expressions such as apply things to a/b/** (all descendants of a/b). > Is there a difference between "all descendants of a/b" and "all > descendants of b"? If a and b represent nodes in your graph then the > path by which you get to a node shouldn't matter surely. The path matters very much which is the whole challenge I'm working on. If it didn't matter, I wouldn't be writing this email :) Because it's a graph, there could be a/b, a/d/e/b, a/z/y/b, etc. There could be any number of ways to get to b. But I need to associate things both with a node/type/thing and with paths so when I query I get info from both. So, yes, I need to apply things to a/b/** that do NOT get applied to a/d/e/b/** and such things. > > 100,000's of paths that would be queried for. And multiply that by > > about 10 for all the other information that would be about each node > > besides hasField. > Don't follow that last statement. You see to have a tree/graph of fields > linked by hasChild. So the nodes are fields whereas hasField applies to > types. Right, as mentioned above there will be other statements like hasFoo, hasBar, etc. about various fields and paths and such. > It's a little hard to follow the problem description in the abstract, if > you have a concrete example that might help. I'm not sure how to be more concrete. I want to model as above, make statements like a/b/** hasChild foo, and query on paths like a/b/c > (1) Use SPARQL property paths. If I understand what you're saying here, it would mean run a query and create statements for all the results? That won't work for me. I forgot to mention, I need to set this up such that if I then go add new fields, I need the statements to automatically apply. So, if I say: (a/b/** hasSomething foo) and after that I create a/b/x, then (a/b/x hasSomething foo) needs to implicitly exist without me creating it. > (2) Use OWL reasoning. > Since you talk about "property paths" rather then pure hierarchies it > may be that you can't express all the sorts of path expressions you need > in this way. Hard to tell from the information so far. I do need rather flexible path expressions so I think I would immediately run into limitations with this approach. > (3) Use custom reasoning > It's possible that you could express your statements about class paths > as a set of rules which match the property path and conclude the > assertion. This is what I expected to need to do. But I'm not understanding how to express those rules, nor how to do a query for a path. > The details depend on what sort of assertions you need to > make. For forward rules this would materialize the graph of assertions > just as option (1) but using rules instead of SPARQL. For backward rules > then you would avoid the storage cost of materialization at the cost of > query time reasoning costs. So, forward rules result in explicit statements being created for everything? That would not work for me--it would be too huge. It sounds like I need to look at backward rules then. > One tricky bit of (3) is that Jena rules have no builtin notion of path > expression. In particular you would need to explicitly define the > descendentOf closure in order to use that in your rules. That might be > better done by relying on the builtin transitive reasoner which would > mean using the same trick as (2) of using subClassOf to represent your > child relationships but now you would have more power than pure OWL > restrictions for expressing your property path assertions. Does subClassOf handle cycles such as a/b/c/b/c/b/c/...? I need to support that. So... How could I model these statements on path expressions and path queries in the rules?
