The functional object property axiom - here in functional syntax - has the form
FunctionalObjectProperty(P)
P is an Object Property Expression, which is one of:
a named object property (PN). Example: FunctionalObjectProperty(:hasBase)
the owl:topObjectProperty
the owl:bottomObjectProperty
an inverse property. Example: FunctionalObjectProperty(ObjectInverseOf(:isBaseOf))
The first is expected. What's the use of the three other variants? These seem to only increase the complexity of parsers, reasoners and APIs. (Yes, marginally.)
The last looks redundant since OWL has an "InverseFunctionalObjectProperty". And who declares top- or bottomObjectProperty as functional ?
I searched through ontologies like geneontology.org. So far, they use nothing else than a named property (PN) as parameter.
Anyway, OWL allows P here, and I may miss the forest for the trees. What is it good for ?
Remark:The same can be asked for other unary property axioms like SymmetricObjectProperty.
See: https://www.w3.org/2007/OWL/refcard
This definition is used in OWL to define what the language syntax considers correct. However there can be some language constructs that are broadly used and other that are syntactically correct but have limited usage.
The definition of the FunctionalObjectProperty axiom allows one to state that an object property expression is functional — that is, that each individual can have at most one outgoing connection of the specified object property expression. 1
The syntax definition of FunctionalObjectProperty is:
Functional Object Properties:
FunctionalObjectProperty := 'FunctionalObjectProperty' '('
axiomAnnotations ObjectPropertyExpression ')'
This definition refers to the ObjectPropertyExpression which is defined as follows.
Object Property Expression definition
ObjectProperty := IRI
ObjectPropertyExpression := ObjectProperty | InverseObjectProperty
InverseObjectProperty := 'ObjectInverseOf' '(' ObjectProperty ')'
This basically mean that there are 2 ways to define an object property.
The first way is to directly define an IRI as an object property.
The second way is to indirectly define an object property as the inverse of an already defined object property.
The difference can be demonstrated in these examples:
Example A: FunctionalObjectProperty(:isGoodFor)
Example B: FunctionalObjectProperty(ObjectInverseOf(:isBaseOf))
The Example A uses an existing Object Property :isGoodFor while the Example B uses the inverse of the defined Object Property :isBaseOf without defining an IRI for it.
The syntax definition for ObjectPropertyExpression includes any Object Property IRI, since it does not exclude it. Therefore the TopObjectProperty and BottomObjectProperty are syntactically valid choices.
So the following are syntactically valid:
FunctionalObjectProperty(owl:topObjectProperty)
FunctionalObjectProperty(owl:bottomObjectProperty)
However owl:topObjectProperty and owl:bottomObjectProperty have predefined semantics in OWL2. So while the above statements are syntactically correct, it would not be a good practice to use them.
Definitions of TopObjectProperty and BottomObjectProperty
Owl defines 2 built-in object properties with the IRIs owl:topObjectProperty and owl:bottomObjectProperty. And have predefined semantics.
The object property with IRI owl:topObjectProperty connects all possible pairs of individuals.
The object property with IRI owl:bottomObjectProperty does not connect any pair of individuals.
Related
I tried to use the same object property between multiple classes, but I got a warning that the same object property has been set multiple times as follows, can you please let me know what is wrong with that and how to solve it? Does this restrict reasoning later on (i.e. confuse the reasoner since the same object property is set multiple times)?
Thanks
Contrary to the comments it actually is very problematic to use the same object property between multiple classes.
What you don't see in your visualization is that in RDF/OWL, the starting point of your relation arrows is modelled as rdfs:domain and the target point of the arrows is modelled as rdfs:range.
The semantic of an OWL class is that it is a set of individuals and rdfs:domain and rdfs:range specify the domain, respectively range of a relation. That is, they specify the sets of allowed values in subject, respectively object position of a triple with that relation in the predicate position.
If you express your example in RDF Turtle it would look like this:
:hasPart rdfs:domain :ClassA, :ClassB;
rdfs:range :ClassB, :ClassC, :ClassD.
This causes multiple problems:
Intersection
The semantic of multiple domains, respectively ranges, is the intersection of those classes, not the union!
Even if we disregard the relation between :ClassB and :ClassD, this means :hasPart is only allowed by individuals that are instances of class C and class D at the same time!
For example, lets say class A is "car", class B is "tire" and class C is "motor". Now you want to say that a car can have tires and motors but what you actually specify is that a car can only have things that are a motor and a tire at the same time!
Unwanted but allowed usage
If you fix the first problem but specifying the union instead of the intersection, it will be very messy in serialized RDF because you need a large amount of triples to represent OWL restrictions such as unions. But even if you do that, you could now connect an instance of class A with an instance of class D, which is not allowed in the image.
Solution
The solution is simple, just separate those relations, for example into :hasB, :hasC and :hasD, although in a real scenario you can probably find a more suitable naming scheme, where the "has" prefix is often not used. For example, in DBpedia, the property for the country of a city is expressed using dbo:country, not dbo:hasCountry.
How do you declare a variable to be the same type as a type parameter used to instantiate a generic class? The following code does not compile:
class
TEST [G, H -> INTEGER]
feature
f (i: INDEXABLE [G, H])
local
y: H
do
y := i.lower -- Type error here.
end
end
The compiler says that the source of the assignment is not compatible with target.
In the current implementation, INDEXABLE [G, H] inherits from TABLE [G, INTEGER]. As a result, lower is of type INTEGER, not H. And INTEGER does not conform to the formal generic type H of the class TEST. This explains the error.
To me, it looks like a mistake in the declaration of class INDEXABLE. It should inherit from TABLE [G, H] instead. Then, the example code would compile.
Type anchoring can be used in those cases:
feature
f (i: INDEXABLE [G, H])
local
y: like i.lower
do
y := i.lower
end
Sometimes a generic type is not used as return type of any accessible feature on a class, so in those cases I like to declare a fake feature specifically to allow anchoring:
class SOME_CLASS [G]
feature
generic_type_anchor: G
do
check
for_anchoring_only: False
-- This method should never actually be called, only used as an anchor in type declarations
end
end
This is particularly useful with complex inheritance trees or when descendant classes close the generics, in which case the correct type is not apparent from the declared type. Personally I tend to use type anchoring whenever values are semantically related as this helps expressing intent, simplifies refactoring (as there are fewer repetitions of types which by definition must match) and facilitates covariance.
Also as a side-note, expanded types (like INTEGER) cannot be used polymorphically (you need a reference for that; if class A is expanded and class B [expanded or reference] inherits A, you could not assign a value of type B to a variable of type A; inheritance from expanded types is implicitly non-conforming), and moreover the compiler disallows inheriting from basic expanded types (INTEGER, BOOLEAN, REAL_64, etc.), therefore the generic constraint in your example makes no sense because H could never be anything but INTEGER.
In OWL, is there a way to state that an individual of a particular class must be related to another individual via a specific object property?
For example, I would like to state that:
forall(x) Object(x) -> exists(y) Shape(y) ^ hasShape(x, y)
i.e., "For all objects, there exists a shape that is the shape of the object."
so that if there is an individual of the type Object that has no shape associated with it, a reasoner would find it to be inconsistent.
I tried an axiom:
Object SubClassOf hasShape min 1 Shape
but it's not working.
It seems like the issue is because Object Property in OWL has no identity, but is there a workaround for this issue?
(I'm using Protege 5.2.0)
You are correct that the meaning of Object SubClassOf hasShape min 1 Shape is that every individual of Object is associated with an individual of Shape via the hasShape property.
So if you create an individual x of type Object without x being associated with an individual of Shape, why does the reasoner not determine that your ontology is inconsistent? The reason for this is due to the open world assumption. Informally it means that the only inferences that the reasoner can make from an ontology is based on explicit information stated in the ontology or what can derived from explicit stated information.
When you state x is an Object, there is no explicit information in the ontology that states that x is not associated with an individual of Shape via the hasShape property. To make explicit that x is not is such a relation, you have to define x as follows:
Individual: x
Types:
Object,
hasShape max 0 owl:Thing
Btw, this problem has nothing to do with identity as you stated.
One solution I found was to make the ontology "closed world", by making owl:Thing equivalent to the set of all individuals defined so far.
Is it possible to express the meaning of xs:unique in OWL?
Say, I define a property hasID whose range is integer. 2 different individuals A and B could not have the same ID. So you don't have A hasID 1 and B hasID 1 at the same time.
That's an inverse functional property. In OWL, there are inverse functional object properties, such that if p is an inverse functional object property then p(A,C) and p(B,C) imply A = B.
From the specification:
9.2.8 Inverse-Functional Object Properties
An object property inverse functionality axiom
InverseFunctionalObjectProperty( OPE ) states that the object property
expression OPE is inverse-functional — that is, for each individual x,
there can be at most one individual y such that y is connected by OPE
with x. Each such axiom can be seen as a syntactic shortcut for the
following axiom:
SubClassOf( owl:Thing ObjectMaxCardinality( 1 ObjectInverseOf( OPE ) ) )
However, OWL doesn't have inverse functional datatype properties. This is the subject of What's the problem with inverse-functional datatype properties? on answers.semanticweb.com. (I'm providing a link to the WaybackMachine's archived version of that page, since the actual site seems to be down.)
In OWL 1; What is the difference between:
Parent subclassOf hasChildren min 1 Thing
and
Parent subclassOf hasChildren some Thing
Are they equivalent as both of them assert that each Parent instance must has at least one value from any class through hasChildren? as we don't specify a particular range for the someValuesFrom restriction?
In OWL 1; What is the difference between:
Parent subclassOf hasChildren min 1 Thing
and
Parent subclassOf hasChildren some Thing
OWL1 doesn't have qualified cardinality restrictions. You can't say
property min n Class
in OWL1. You can use unqualified cardinality restrictions (1), and qualified existential restrictions, like:
property min n
property some Class
In OWL 2, where you do have qualified cardinality restrictions, you have the ability to write
property min n Class
and you're absolutely right that the following are equivalent:
property min 1 Class
property some Class
and as a special case, the following are equivalent:
property min 1 owl:Thing
property some owl:Thing
The someValuesFromin OWL is equivalent to the existential quantifier in predicate logic:
In predicate logic, an existential quantification is a type of quantifier, a logical constant which is interpreted as "there exists," "there is at least one," or "for some." It expresses that a propositional function can be satisfied by at least one member of a domain of discourse. In other terms, it is the predication of a property or relation to at least one member of the domain. It asserts that a predicate within the scope of an existential quantifier is true of at least one value of a predicate variable.
Keeping this in mind, please refer to the definition of Restirction:
OWL Lite allows restrictions to be placed on how properties can be used by instances of a class.
And the definition of Cardinality:
OWL (and OWL Lite) cardinality restrictions are referred to as local restrictions, since they are stated on properties with respect to a particular class. That is, the restrictions constrain the cardinality of that property on instances of that class.
In OWL, someValuesFrom has been defined as:
The restriction someValuesFrom is stated on a property with respect to a class. A particular class may have a restriction on a property that at least one value for that property is of a certain type.
And minCardinality has been defined as:
If a minCardinality of 1 is stated on a property with respect to a class, then any instance of that class will be related to at least one individual by that property.
So, although logically they are the same, they represent different ideas.