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
