On 10/05/13 09:36, Michael Trosin wrote:
Hi,
thank you very much for the detailed explanation and the link. Now I am a
little bit confused which way is better: Using listDeclaredProperties or
using the self-implemented listProperties provided by David Jordan.
Well, as I said in my email to David, the two methods solve completely
different problems. Which one is right for you depends on what you're
trying to achieve, which, as far as I know, you haven't stated.
Well, I made a short example to demonstrate, what the problem is. I have an
ontology which has three classes (Home, Animal and its subclass Cat). Each
animal has the DatatypeProperty "hasFur" and a cat "hasHome"
(objectProperty). A home also has a "hasAddress". The ontology-file I
created is attached at the end of this mail.
Now using this peace of code returns no properties:
public static void testProperties(OntModel m) throws Exception
{
// load the ontclass
OntClass oc = m.getOntClass("
http://www.semanticweb.org/aslan/ontologies/2013/4/untitled-ontology-3#Home
");
// check
if(oc == null)
throw new Exception("ont-class could not be loaded!");
// try to list the properties of this class (should be hasAddress)
ExtendedIterator<OntProperty> ei = oc.listDeclaredProperties(true);
System.out.println("Properties:");
while (ei.hasNext())
{
OntProperty p = ei.next();
System.out.println(p.getLocalName());
}
System.out.println("Finished listing...");
}
But, if I call listDeclaredProperties with false, I get all the
datatype-Properties, what seems strange to me. The link you provided only
explains the effects of inferred properties on instances, but on classes
there shouldn't be anything inferred (I mean in this simple ontology). I am
again wrong? :-)
Maybe there is a big misunderstanding, what I think how ontologies work.
Could you explain, why this doesn't give the expected result of hasAddress?
Great thanks in advice for all you help.
Although properties in RDF play a similar role to slots in a frame-based
system, there is not really any notion in RDF of the properties *that
belong to* a class. In an open-world representation like RDF/OWL, you
can attach any property to any resource. That may entail additional
information, including that the model is then inconsistent, but there's
nothing to stop you doing it. Put another way, if you want to ask "which
properties can I use with this class", the correct answer is "any
property from any ontology anywhere".
Lots of people have found this inconvenient. When designing an ontology,
you have a sense of the properties you-the-designer *expect* to be used
with a particular class. A common way of documenting this is to use
rdfs:domain:
:Cat a owl:Class.
:furLength a owl:DatatypeProperty;
rdfs:domain :Cat.
This doesn't, in fact, restrict :furLength to only being used on
resources that are already known to be :Cat instances. It allows you to
infer that any resource with a :furLength must, in fact, be a :Cat.
However, we found that many people were using rdfs:domain *as though* it
imposed just such a restriction, and that can be very useful. A good use
case is a form designer: "I want to create a form to instantiate
instances of :Cat classes, which properties should I provide form fields
for?" Clearly the answer of "every property in the entire ontology" does
not capture the intent that certain properties are expected to appear
with cats.
Jena's listDeclaredProperties method is an attempt to capture this
informal semantics of the association of some properties to certain
classes. It's not officially part of RDF, and there is no formal
specification of what the behaviour should be. However, we use the
rdfs:domain, and the heuristic that a property used with an instance of
a class that entails no additional type information is an property "of"
that class.
In your instance, the datatype properties such as :hasHome or :hasFur
have no stated rdfs:domain, so implicitly the rdfs:domain is
rdfs:Resource (or owl:Thing if you prefer). So by inheritance, every
resource "has" the property :hasFur. That's why :hasFur appears in the
non-direct case of lDP(), and disappears in the direct case.
As for the :Cat class, you're not using rdfs:domain to associate
properties with classes, but qualified cardinality restrictions (:Cat is
a sub-class of the class of resources that have at least one :hasHome
property whose value is a :Home). While that conveys a similar intent to
the global rdfs:domain axiom, and arguably could be covered by the same
argument as above, it's not a case that the code currently covers
(because the edge cases get very complex).
Bottom line: if you need the lDP() kind of association between classes
and properties, either use rdfs:domain axioms, or else you could write a
SPARQL query to extract the associations you want.
Ian
