Does SWRL support classical negation in Protege? - owl

I wanted to try the following rule:
(not Person)(?x) -> NonHuman(?x) which is provided here - https://github.com/protegeproject/swrlapi/wiki/SWRLLanguageFAQ#does-swrl-support-classical-negation
and i got this:
Is classical negation supported in Protege 5.5.0? If yes, how I can make the following rule to be okay?
Thanks in advance!

From https://github.com/protegeproject/swrlapi/issues/63:
Unfortunately, the SWRLAPI's parser does not support OWL class expressions in rules.
There is no timeline for their inclusion.
Fortunately, one can use the Rules view (Windows > Views > Ontology Views > Rules):
Rule: (not Person)(?x) -> NonHuman(?x) is parsed correctly and works as intended.
Actually, you do not need SWRL in this particlular case. Just write (not Person) SubClassOf NonHuman in the General class axioms section, or define NonPerson first, if you don't like GCI axioms.
Don't forget about the OWA.

Related

What is the difference between Association and Composition Aggregation in Autosar domain

I am reading Autosar document and in one of the document (Autosar_TemplateModelingGuideline.pdf), it says that:
Composite aggregation, forming a whole-part relationship
Regular association, expressing a reference from the associating to
the associated model element
My question is: what is the difference between these two in practice? How do I have to interpret them in a class diagram, e.g. the Com Module in Autosar.:
The AUTOSAR COM module’s Configuration Overview
Consider Specified class ComGwSignalRef surrounded with a red rectangle. This class has a composition relation with ComGwSignalRef class and two regular association with ComGroupSignal and ComSignal.
How would you interpret this as a developer and how do you implement in C?
if regular association is a reference to an object that has independent life from ComGwSignalRef why designer do not use instanceRef here?
if it is not a reference, why did the designer not use composition?
PS. There is a concept in Autosar "InstanceRef" which is used for reference for independent object with independent lifecycle.
Maybe you should also consider the following:
The Com Configuration is an instance of the EcuC configuration meta-model as defined in the AUTOSAR_TPS_EcuConfiguration.
The ComGwSignalRef is of type EcucChoiceContainerDef, and as such, the two destination associations of ComSignal and ComGroupSignal have a meaning. Only one of these "choices" can be selected in the final configuration as a reference. In AUTOSAR metamodel, that is the definition of how EcucChoiceContainerDef works, in UML you might need here an additional constraint element to define the XOR relation of two associations.
An object can only be composed as part of one object.
A <>- C -<>B
In the diagram above C is composed in A and B. This would lead to the following instances:
a: A <>- c: C -<> b:B
Now the specific instance c is now part of both a and b.
What happen would with c if b goes out of scope? By the semantics it should be destroyed and not be destroyed (a still exists).
Or more pointed:
Take Alice,Bob, and Collar Bone as examples. Alice’s collar bone cannot be part of Bob.
UML is a modeling language and has not the same expressiveness as, say a C compiler. This is by design to simplify things.
Remember: All models are wrong, but some are useful. — George E. P. Box

Parsing inline functional syntax axioms with OWL API

I need to parse some axioms represended as strings in functional syntax
in order to add to an existing ontology or compare with its axioms.
(i.e. convert the string like 'ObjectPropertyAssertion(:crosses :flow :line)' to an OWLAxiom object).
I know it is possible for the machester syntax by the ManchesterOWLSyntaxParserImpl class with the setStringToParse() and parseAxiom() methods.
Has the functional parser got the simular feature?
Or is there third-part implementation or an example that allows to easily parse inline strings above existing ontology?
That feature is unique to Manchester syntax, the other OWLAPI parsers do not support it.
However, if the axiom you wish to parse is self contained (i.e., no prefixes and no declarations required to disambiguate entities) a workaround would be to wrap it in an empty ontology and parse that.
Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
Ontology(<http://example.com/temp>
# add your axiom string here
)
Then just retrieve all axioms and discard the ontology.

What are the consequences of declaring a property subPropertyOf a DublinCore property

When creating an OWL ontology, what are the consequences of declaring :
ex:myHasPart a owl:ObjectProperty .
ex:myHasPart owl:subPropertyOf <http://purl.org/dc/terms/hasPart> .
In OWL 1 : I read from http://bloody-byte.net/rdf/dc_owl2dl/ that it implies that ex:myHasPart will be an AnnotationProperty. Can it be both an ObjectProperty and an AnnotationProperty ?
In OWL 2 : What would be the consequences/entailments ?
How can I choose in Protégé to work in OWL1 or OWL2 ?
Additionnally, what are the consequences in terms of OWL-DL vs. OWL-Full ? would my ontology still be at the OWL-DL level ?
Is it a good practice to declare subProperties of dcterms like this ? I think I need a general explanation on this.
What could be the alternative to link ex:myHasPart with dcterms:hasPart ? rdfs:seeAlso ? skos:broadMatch ?
From the two triples you write, we can just say that if you have a triple <x> ex:myHasPart <y>, then we can infer <x> dc:hasPart <y> (in both OWL 1 and OWL 2, using either direct semantics or RDF-based semantics).
But the complete consequences of the axioms can only be fully estimated by knowing what else is in your ontology. If you only have those two triples, your ontology is not in OWL (1/2) DL. But reasoners won't care, they'll usually assume that dc:hasPart is an object property too, and things will be just fine. Also, if you have an additional statement saying:
dc:hasPart a owl:AnnotationProperty .
then the ontology is not valid OWL DL, nor OWL 2 DL, no matter what else you have in it (an IRI can only be denoting at most one type of property, annotation, datatype, or object). It is still usable in many OWL tools that will not care (like Protégé, for instance). Reasoners probably don't care either, as long as you don't use the properties in bizarre ways, e.g., with both literals and non literals.
To answer specifically to your questions:
In OWL 1 : I read from http://bloody-byte.net/rdf/dc_owl2dl/ that it implies that ex:myHasPart will be an AnnotationProperty. Can it be both an ObjectProperty and an AnnotationProperty ?
No, the two triples imply that ex:myHasPart is an owl:ObjectProperty. In an OWL 2 ontology, a property cannot be object and annotation at the same time. In an OWL 2 Full ontology, they can (an OWL 2 Full ontology is just an RDF graph). In OWL 1, an OWL DL ontology cannot have an object property that is an annotation property at the same time, while an OWL Full ontology can.
In OWL 2 : What would be the consequences/entailments ?
Pretty much the same thing as in OWL 1, but it depends what semantics you are using: Direct Semantics or RDF-based semantics? The direct semantics only applies to OWL 2 ontologies, not to OWL 2 Full ontologies, so you would have to, at least, declare your ontology <yourOnto> a owl:Ontology and declare the term dc:hasPart as an owl:objectProperty. Reasoners can be more tolerant. In any case, there is not going to be anything bad happening, unless you are messing up with the rest of the ontology.
How can I choose in Protégé to work in OWL1 or OWL2 ?
You can choose a version of Protégé that does not support OWL 2 (if you can still manage to find one). Otherwise, any version after 4.0 uses OWL 2. But from a syntactic point of view, there is no reason to restrict to OWL 1. The reasoning is done independently from the editor in Protégé, so whether you have OWL 1 or OWL 2 reasoning depends on which plugin you have. However, OWL reasoners that do not support OWL 2 are simply obsolete, there is not much sensible reasons to still use them.
Additionnally, what are the consequences in terms of OWL-DL vs. OWL-Full ? would my ontology still be at the OWL-DL level ?
I think I already explained this.
Is it a good practice to declare subProperties of dcterms like this ? I think I need a general explanation on this.
I do not see any reason why it would be considered good practice, but I don't see a reason to actively prevent people from doing so.
What could be the alternative to link ex:myHasPart with dcterms:hasPart ? rdfs:seeAlso ? skos:broadMatch ?
Your suggestions seem valid to me. But do you really need to make that link explicit?

SWRLTab usage in Protege

Everyone,
I'm used to Protégé but now, I'm trying to use SWRLTab, a Protégé plugin.
The problem is that I'm really not familiar with the SWRL rule-syntax. Let's have fun with my problem :
I've an well-known ontology, called "pizza". Let's say I've a 4cheesesPizza, subclass of Pizza.
I don't want to write the "hasTopping exactly 4 CheesyTopping" thing in the "Equivalent To" tab of Protégé BUT I want to write it in the SWRL Rule syntax. (yes I know it's stupid, but this is an example and in my real case, write a rule makes sense).
I tried something like Pizza(?p) ^ hasTopping(?p,?t) but next, I'm quite blocked. I don't know what to do.
Moreover, when I launch OWL + SWRL -> Drools , in the Inferred Axioms there's already more than 100 lines, It's unreadable.
If someone has the solution,
Thanks, Clément
What you want to do in SWRL is not possible. I.e. SWRL will need to count the number of individuals that are in a hasTopping relation with a specific individual p of type Pizza. SWRL cannot do that, but the OWL reasoner can, hence what you have specified in Protege is the correct way to do it.
As an example for SWRL syntax, assume you have classes ExpensiveTopping and ExpensivePizza you could add a rule in the SWRL tab to determine an expensive pizza:
Pizza(?p) ^ hasTopping(?p,?t) ^ ExpensiveTopping(?t) -> ExpensivePizza(?p).

Could we use owl:sameAs in an OWL restriction?

For example, I have three classes: Flock, Bird, Velocity. I also have two properties: hasMember (the domain is Flock, range is Bird), and hasAttribute (the domain is Bird, and the range is Velocity). Now I want to add a EquivalentClass restriction to Flock class as the definition. Let consider a very simple definition: in a flock, all birds have the same velocity. How to express this in OWL?
Warning: this answer is in fact incorrect, please look at the comments to see why.
To the question "Could we use owl:sameAs in an OWL restriction?" the answer is no, not in an OWL (2) ontology. However, you can do whatever you like in an OWL Full ontology (i.e., an RDF graph interpreted according to the OWL RDF-based semantics). Yet, this is irrelevant to the details of your question where you want to say something about the velocity of the birds in a flock.
There is a solution to your problem within the limits of OWL 2 DL. Introduce a property flockVelocity and make the property chain hasMember o hasAttribute a subproperty of flockVelocity. Make flockVelocity a functional property and you're done. Alternatively, you could define a cardinality restriction on flockVelocity. In Turtle:
:hasMember a owl:ObjectProperty;
rdfs:domain :Flock;
rdfs:range :Bird .
:hasAttribute a owl:ObjectProperty; # why not :hasVelocity?
rdfs:domain :Bird;
rdfs:range :Velocity .
:flockVelocity a owl:ObjectProperty, owl:FunctionalProperty;
owl:propertyChainAxiom (:hasMember :hasAttribute) .
Done. If you don't care about being in OWL DL and allow yourself total OWL Full freedom, you could use a blank node instead of :flockVelocity such that you don't have to introduce an artificial property name.

Resources