Odd, can't explain that.
As I've mentioned before reasoning over a database backend, especially
an SDB one, is a really bad idea and will be very slow. But I can't
explain why a simple createIndividual should take quite so long.
Try with in-memory v. SDB and with/without reasoning to isolate some of
the effects.
You may need a write-through in-memory cache to get usable performance.
Dave
On 01/04/13 18:47, David Jordan wrote:
I added the call to prepare().
I changed the ontology to the following, it did not really make much difference
in performance, still very slow.
:numWheels
a owl:FunctionalProperty ;
a owl:DatatypeProperty ;
rdfs:domain :Vehicle ;
rdfs:range xsd:integer .
:Motorcycle
a owl:Class ;
rdfs:subClassOf :Vehicle ;
a [ a owl:Restriction ;
owl:hasValue "2"^^xsd:nonNegativeInteger ;
owl:onProperty :numWheels
] .
-----Original Message-----
From: Joshua TAYLOR [mailto:[email protected]]
Sent: Monday, April 01, 2013 12:45 PM
To: [email protected]
Subject: Re: performance of createIndividual with OntModel
On Mon, Apr 1, 2013 at 11:34 AM, David Jordan <[email protected]> wrote:
I am getting a performance result of around 1 minute clock time to execute
OntClass.createIndividual. Is this expected? Below is the relevant part of the
ontology and the Java code. Every line of code runs fast except the
createIndividual. Is this due to reasoning being kicked off for the first time?
I’ll see if adding a second individual is just as slow.
Here is the Java code.
Model model = getNamedModel(VEHICLE_MODEL_NAME);
OntModelSpec spec = new
OntModelSpec(OntModelSpec.OWL_DL_MEM_RULE_INF);
OntModel omodel = ModelFactory.createOntologyModel(spec, model);
OntClass bikeClass = omodel.getOntClass(uriBase + "Motorcycle");
Individual myBike = bikeClass.createIndividual(uriBase +
"data/myBike");
I don't see anything strange about this Jena code (but someone else could reply
with something I don't know about), but something looks a bit strange about the
ontology that you posted. That could, as you suggested, cause some trouble with
the reasoner, but I don't know whether it has anything to do with the strange
behavior you're seeing.
If nothing else, these are thing that you could play around with and see
whether they change the behavior (in case it is a reasoner issue).
veh:numWheels a owl:DatatypeProperty ;
rdfs:domain veh:Vehicle ;
rdfs:range xsd:integer .
veh:Vehicle
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:maxCardinality """1
"""^^xsd:nonNegativeInteger ;
owl:onProperty veh:numWheels
] .
Rather than using a restriction here, you could also just as well say that
veh:numWheels is a functional property. This shouldn't make a difference,
though, since they'll have the same effect; I'm just noting it because it's a
somewhat simpler construct.
veh:Motorcycle
a owl:Class ;
rdfs:subClassOf veh:Vehicle ;
owl:equivalentClass
[ a owl:Restriction ;
owl:hasValue "2"^^xsd:nonNegativeInteger ;
owl:onProperty veh:numWheels
] .
I wonder whether that equivalent class axiom shouldn't be a subclass axiom? This says that
*anything* that has numWheels = 2 is a motorcycle. Now, anything that has numWheels at all is a
Vehicle (based on the domain of numWheels), so there won't be any inconsistency with a non-Vehicle
that has 2 wheels, since by virtue of it having wheels, it's a vehicle. But you'll suddenly find
that rickshaws, bicycles, and chariots are now all motorcycles, since they have two wheels. If you
make this a subclass axiom, however, you'll still be able to go from "x is a motorcycle"
to "x has two wheels", but not in the other direction. Equivalent classes can cause some
complexity increase, but I don't know whether that leads to the symptoms you're having.
//JT
