Hi,
On 08/08/16 00:23, Simon Schäfer wrote:
Hello there,
I'm currently designing a system on top of Jena (or on top of semantic web
technologies in general) and I arrived at the point where I need to get
inference support for SPARQL queries up and running. I looked at
https://jena.apache.org/documentation/inference/ but I'm having problems to
understand how to exactly design what I need. I would welcome if someone could
look at my use case and tell me if it makes sense to design it this way in
general and how to tell Jena to do the inference support.
I think my use case can be described with the following two SPARQL queries:
prefix sd:<http://x.test/schema/Decl/0.1/>
prefix sc:<http://x.test/schema/Class/0.1/>
prefix c:<http://x.test/data/Class/0.1/>
prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#>
prefix s:<http://schema.org/name>
insert data {
sc:name rdfs:subPropertyOf sd:name .
sc:name a s: .
sd:name a s: .
c:ClassName a sc: .
c:ClassName sc:name "ClassName" .
}
This doesn't matter for your later questions but this example looks like
it is confusing classes and properties.
s: seems to be a property so the relationship between sc: and sd: to s:
should be rdfs:subPropertyOf.
Using the namespace itself (e.g. sc:) as the URI for a class is not
wrong but is unusual and might cause confusion.
The purpose of the snippet above is to create an object of type
`http://x.test/schema/Class/0.1/` and give it a name. There is also the type
`http://x.test/schema/Decl/0.1/`, which is a super type of the previous type.
In the above snippet it's a super property not a super type.
The types of the names are not important, the only thing that is important is
that `Class` shares all the properties that are also part of `Decl`.
Nothing in the above says that. There is nothing here about properties
being "part of" Class or Decl. In RDFS/OWL properties exist independent
of classes. That can be related (via domain/range or the various OWL
restrictions) but it's not like object oriented modelling.
This query works fine but the next one doesn't:
prefix sd:<http://x.test/schema/Decl/0.1/>
prefix sc:<http://x.test/schema/Class/0.1/>
select * where {
# This doesn't give back any results:
?s sd:name ?o .
# This would work fine:
# ?s sc:name ?o .
}
The purpose of this query is to select all names. Unfortunately at the moment
it only works when I ask for the name of the `Class`. If I ask for the name of
the `Decl` I don't get back anything because there is no relation between the
two different names yet. What I need here is basically a dynamic dispatch as it
exists for Java methods for example. I want to ask for the property that is
part of the supertype but I want to store it as a property of the subtype.
Now, there are two concrete questions:
- Does it make sense to design the system this way? I'm more or less mimicking
the typical inheritance model of object oriented languages here but I'm not
sure if that is the way to go. The two types `Class` and `Decl` can be created
independently from each other and the subtype relationship may be created by
another party.
The subPropertyOf relation is a perfectly reasonable thing to use, and,
given inference support, the above query will work. Whether it's the
right way to design your system I can't comment on since I've no idea
what the system is and what you are trying to achieve.
The one note of caution I would repeat is that RDSF/OWL modelling and OO
modelling are quite different. You can achieve similar effects in both
cases but don't use OO behaviour as a guide to what RDFS/OWL inference
will give you otherwise you'll get surprised :)
- How to express the above relationship in Jena? I found Jenas
`GenericRuleReasoner` but this one doesn't seem to do what I need. It seems to
infer additional information based on a set of rules and stores this additional
information in the database. I don't think that the relationship I have should
be stored in the database. I think the moment when the second query is run,
Jena internally needs to find out about the relationship (based on a set of
rules) and find more information based on the rules.
Think of that as a cache. Whether the reasoner keeps a note of
inferences it has already made doesn't change the behaviour.
Though in fact the rule reasoner can support backward chaining (in which
the queries are answered on demand) as well as forward chaining (in
which the answers are kept).
For your example above I would use the default RDFS reasoner
configuration. It uses and GenericRuleReasoner under the hood with a mix
of forward and backward rules.
Dave
