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

Reply via email to