-
Notifications
You must be signed in to change notification settings - Fork 0
Examples
This page contains examples for
- the configuration file
- SHACL shapes
- SWRL rules as mutation operators
The following configuration is an example of how to mutate an OWL-EL ontology by only using mutation operators that guarantee that the resulting ontology is again within the OWL-EL fragment. Mainly, the configuration lists 55 mutation operators that are designed to add and delete all kinds of features that are allowed in OWL-EL ontologies.
strict_parsing: false
seed_graph:
file: examples/wiki/elMutations/ore_ont_155.owl
type: owl
output_graph:
file: examples/wiki/elMutations/mutatedOnt.owl
overwrite: true
type: owl
number_of_mutations: 5
mutation_operators:
- module:
location: org.smolang.robust.mutant.operators
operators:
# declaration axioms
- className: DeclareClassMutation
- className: DeclareObjectPropMutation
- className: DeclareDataPropMutation
# sub-class axioms
- className: AddSubclassRelationMutation
- className: RemoveSubclassRelationMutation
#equivalent-class axioms
- className: AddEquivalentClassRelationMutation
- className: RemoveEquivClassRelationMutation
#disjoint-class axioms
- className: AddDisjointClassRelationMutation
- className: RemoveDisjointClassRelationMutation
#replace class
- className: ReplaceClassWithTopMutation
- className: ReplaceClassWithBottomMutation
- className: ReplaceClassWithSiblingMutation
#add properties of object properties
- className: AddReflexiveObjectPropertyRelationMutation
- className: AddTransitiveObjectPropertyRelationMutation
#domains and ranges of properties
- className: AddObjectPropDomainMutation
- className: AddDataPropDomainMutation
- className: RemoveDomainRelationMutation
- className: AddObjectPropRangeMutation
- className: AddDataPropRangeMutation
- className: RemoveRangeRelationMutation
#property hierarchy
- className: AddSubObjectPropMutation
- className: AddSubDataPropMutation
- className: RemoveSubPropMutation
- className: AddEquivObjectPropMutation
- className: AddEquivDataPropMutation
- className: RemoveEquivPropMutation
- className: AddPropertyChainMutation
#complex class expressions
- className: AddObjectIntersectionOfMutation
- className: AddELObjectOneOfMutation
- className: AddObjectSomeValuesFromMutation
- className: AddObjectHasValueMutation
- className: AddDataHasValueMutation
- className: AddObjectHasSelfMutation
- className: AddELDataIntersectionOfMutation
- className: AddELDataOneOfMutation
- className: AddELSimpleDataSomeValuesFromMutation
#misc
- className: CEUAMutation
- className: AddDatatypeDefinition
- className: AddHasKeyMutation
# -------------Abox-----------------------
# individuals
- className: AddIndividualMutation
# adds owl named individual
- className: RemoveIndividualMutation
- className: AddClassAssertionMutation
- className: RemoveClassAssertionMutation
#relations between individuals
- className: AddObjectPropertyRelationMutation
- className: RemoveObjectPropertyRelationMutation
- className: AddNegativeObjectPropertyRelationMutation
- className: RemoveNegativePropertyAssertionMutation # also applies to data properties
# equivalence of individuals
- className: AddSameIndividualAssertionMutation
- className: RemoveSameIndividualAssertionMutation
- className: AddDifferentIndividualAssertionMutation
- className: RemoveDifferentIndividualAssertionMutation
#data properties
- className: BasicAddDataPropertyRelationMutation
- className: RemoveDataPropertyRelationMutation
- className: AddNegativeDataPropertyRelationMutation
We provide some example SHACL shapes that can be useful to generate RDF graphs. We demonstrate the following cases
- existence of a specific triple
- conditions targeting classes of nodes
- connection of different shapes
- complex property paths
There are also plenty of examples in the SHACL standard.
We can use SHACL shapes to ensure that a specific triple is contained in the generated graph. E.g., the following shape ensures that the triple (:A, rdfs:subClassOf :B) is contained in the generated graph.
This is the example using turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
:shape0 rdf:type sh:NodeShape;
sh:targetNode :A ;
sh:property [ sh:hasValue :B;
sh:minCount 1;
sh:path rdfs:subClassOf
].
We can use more general SHACL shapes to express not only conditions about specific nodes but about all nodes that are of some type. The following example targets all nodes that are within the class :Dog and requires that they are connected via a relation with the property :hasOwner to at least one node that is in the class :Human. I.e., every dog needs to have an owner that is a human.
This is the example using turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
:shape1 a sh:NodeShape ;
sh:targetClass :Dog ;
sh:property [
sh:path :hasOwner ;
sh:minCount 1 ;
sh:class :Human ;
].
Different shapes can refer to each other by their name. E.g. the following shapes work together to express that all subway cars should be at a final station, where a final station is one that has at most one neighboring station. Note, that :FinalStation does not have a target, i.e., this shape is only relevant because it is mentioned by the other shape.
This is the example using turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
:FinalStation a sh:NodeShape ;
sh:property [
sh:path :nextStation ;
sh:maxCount 1 ;
].
:SubwayAtStart a sh:NodeShape ;
sh:targetClass :SubwayCar ;
sh:property [
sh:path :isAt ;
sh:node :FinalStation ;
].
One can express complex paths instead of single properties. The following describes that :alice is at a station, which is connected via :nextStation to the station that is closest to her home. The term (^:closestStation) refers to the inverse of a path.
This is the example using turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
:shape3 a sh:NodeShape ;
sh:targetNode :alice ;
sh:property [
sh:property sh:path (:atStation)/(:nextStation*)/(^:closestStation);
sh:hasValue :aliceHome ;
sh:minCount 1;
].
We show some example SWRL rules that describe mutation operators. In particular, we show rules that demonstrate the usage of our custom built-ins.
We show rules for
- simple selection of triples / adding a triple
- using data properties
- non-existence of a triple
- removing a triple
- adding a new node
- removing an existing node
- replacing one node with another one
Selecting triples can be done with the swrl:IndividualPropertyAtom atoms. We generalize the standard SWRL interpretation and allow arbitrary IRIs to occur as arguments. The following mutation operator selects a triple with property :p and adds a triple to the RDF graph where the subject and object are swapped.
The following is the rule using turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix swrl: <http://www.w3.org/2003/11/swrl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
:x rdf:type swrl:Variable .
:y rdf:type swrl:Variable .
:p rdf:type owl:ObjectProperty .
[ rdf:type swrl:Imp ;
swrl:body [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:IndividualPropertyAtom ;
swrl:propertyPredicate :p ;
swrl:argument1 :x ;
swrl:argument2 :y
] ;
rdf:rest rdf:nil
] ;
swrl:head [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:IndividualPropertyAtom ;
swrl:propertyPredicate :p ;
swrl:argument1 :y ;
swrl:argument2 :x
] ;
rdf:rest rdf:nil
]
] .
Unlike in the example, the arguments do not need to be variables but can also be specific node.
We allow to encode data properties to refer to relations with literals. The following rule targets relations where the object is the number 0.5 and adds a relation with the same relation but with a the new literal "a new value"^^xsd:string as the object.
The following is the rule in turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix swrl: <http://www.w3.org/2003/11/swrl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
:x rdf:type swrl:Variable .
:dp rdf:type owl:DatatypeProperty .
[ rdf:type swrl:Imp ;
swrl:body [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:DatavaluedPropertyAtom ;
swrl:propertyPredicate :dp ;
swrl:argument1 :x ;
swrl:argument2 0.5
] ;
rdf:rest rdf:nil
] ;
swrl:head [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:DatavaluedPropertyAtom ;
swrl:propertyPredicate :dp ;
swrl:argument1 :x ;
swrl:argument2 "a new value"^^xsd:string
] ;
rdf:rest rdf:nil
] ;
] .
We use owl:NegativePropertyAssertion as a built-in to implement negative assertions. E.g., the following mutation operator selects all nodes that are of type :B but not of type :A. I.e., in this specific case, the triple that should not exist is a rdf:type relation. In general, all kinds of triples / properties can be used in such a negative assertion. The consequence of the following operator is to add the assertion (:x rdf:type :A) to the graph.
The following is the SWRL rule as turtle code:
@prefix : <https://smolang.org/swrlTest#> .
@prefix swrl: <http://www.w3.org/2003/11/swrl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
:x rdf:type swrl:Variable .
[ rdf:type swrl:Imp ;
swrl:body [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:BuiltinAtom ;
swrl:builtin owl:NegativePropertyAssertion;
swrl:arguments ( :x
rdf:type
:A
)
] ;
rdf:rest [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:ClassAtom ;
swrl:classPredicate :B ;
swrl:argument1 :x
] ;
rdf:rest rdf:nil
]
] ;
swrl:head [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:ClassAtom ;
swrl:classPredicate :A ;
swrl:argument1 :x
] ;
rdf:rest rdf:nil
]
] .
We use owl:NegativePropertyAssertion as a built-in in the head of a rule to encode a triple that is removed from the RDF graph when the mutation operator is applied. The following rule selects triples that specify that the variable :x is within the class :A. The consequence is, that such a triple is removed from the graph.
The following is the rule using turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix swrl: <http://www.w3.org/2003/11/swrl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
:x rdf:type swrl:Variable .
[ rdf:type swrl:Imp ;
swrl:body [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:IndividualPropertyAtom ;
swrl:propertyPredicate rdf:type ;
swrl:argument1 :x ;
swrl:argument2 :A
] ;
rdf:rest rdf:nil
] ;
swrl:head [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:BuiltinAtom ;
swrl:builtin owl:NegativePropertyAssertion;
swrl:arguments ( :x
rdf:type
:A
)
] ;
rdf:rest rdf:nil
]
] .
The following operator adds a new node to the graph. In particular, a old node that is of type pipe:PipeSegment is selected. A new node of type pipe:PipeSegment is added and connected via pipe:nextTo to the selected node.
The following is the rule in turtle notation:
@prefix swrl: <http://www.w3.org/2003/11/swrl#> .
@prefix rdfmutate: <https://smolang.org/rdfMutate#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix pipe: <http://www.ifi.uio.no/tobiajoh/miniPipes#> .
:old rdf:type swrl:Variable .
:new rdf:type swrl:Variable .
[ rdf:type swrl:Imp ;
swrl:body [ rdf:type swrl:AtomList> ;
rdf:first [ rdf:type swrl:BuiltinAtom ;
swrl:builtin rdfmutate:newNode;
swrl:arguments ( :new )
] ;
rdf:rest [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:ClassAtom> ;
swrl:classPredicate> pipe:PipeSegment ;
swrl:argument1> :old
] ;
rdf:rest rdf:nil
]
] ;
swrl:head [ rdf:type swrl:AtomList> ;
rdf:first [ rdf:type swrl:ClassAtom ;
swrl:classPredicate pipe:PipeSegment ;
swrl:argument1 :new
] ;
rdf:rest [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:IndividualPropertyAtom ;
swrl:propertyPredicate pipe:nextTo ;
swrl:argument1 :old ;
swrl:argument2 :new
] ;
rdf:rest rdf:nil
]
]
] .
The following mutation operator deletes a node from the graph. In particular, a node of type pipe:PipeSegment is selected and removed from the graph.
The following is the SWRL rule in turtle syntax.
@prefix swrl: <http://www.w3.org/2003/11/swrl#> .
@prefix rdfmutate: <https://smolang.org/rdfMutate#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix pipe: <http://www.ifi.uio.no/tobiajoh/miniPipes#> .
:s rdf:type swrl:Variable .
[ rdf:type swrl:Imp ;
swrl:body [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:ClassAtom ;
swrl:classPredicate pipe:PipeSegment ;
swrl:argument1 :s
] ;
rdf:rest rdf:nil
] ;
swrl:head [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:BuiltinAtom ;
swrl:builtin rdfmutate:deleteNode;
swrl:arguments ( :s )
] ;
rdf:rest rdf:nil
]
] .
Using our built-in rdfmutate:replaceWith, one can replace a node with another node everywhere in the graph. The following rule replaces the node :a with the node :b. The rule has an empty body, i.e. there are no restrictions to when the rule is applied (this is also not necessary, as there are no variables in this example).
The following is the rule using turtle syntax:
@prefix : <https://smolang.org/swrlTest#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix swrl: <http://www.w3.org/2003/11/swrl#> .
@prefix rdfmutate: <https://smolang.org/rdfMutate#> .
[ rdf:type swrl:Imp ;
swrl:body rdf:nil ;
swrl:head [ rdf:type swrl:AtomList ;
rdf:first [ rdf:type swrl:BuiltinAtom ;
swrl:builtin rdfmutate:replaceWith;
swrl:arguments ( :a
:b
)
] ;
rdf:rest rdf:nil
]
] .
Overview
User Documentation
Developer Documentation
Misc