swrlx:makeOWLThing is creating only one individual - owl

Using Protege and SWRL tab, I have the ontology mentioned hereinafter. It is composed of the Class Test and the class Shadow, where Test has three individuals t1, t2, t3. I was trying to define an SWRL rule that creates an individual of Shadow class for each existing individual of Test, the rule is
Test(?x) ^ swrlx:makeOWLThing(?new, ?x) -> Shadow(?new)
QUESTIONS:
Only one individual of Shadow, named fred is created, instead of three (corresponding to t1, t2, t3).
How to control the naming of the resulting individual which is always named fred?
Prefix(:=<http://www.semanticweb.org/hilal/ontologies/2016/5/untitled- ontology-58#>)
Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)
Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)
Ontology(<http://www.semanticweb.org/hilal/ontologies/2016/5/untitled- ontology-58>
Declaration(Class(:Shadow))
Declaration(Class(:Test))
Declaration(NamedIndividual(:t1))
Declaration(NamedIndividual(:t2))
Declaration(NamedIndividual(:t3))
Declaration(AnnotationProperty(<http://swrl.stanford.edu/ontologies/3.3/swrla.owl#isRuleEnabled>))
############################
# Named Individuals
############################
# Individual: :t1 (:t1)
ClassAssertion(:Test :t1)
# Individual: :t2 (:t2)
ClassAssertion(:Test :t2)
# Individual: :t3 (:t3)
ClassAssertion(:Test :t3)
DLSafeRule(Annotation(<http://swrl.stanford.edu/ontologies/3.3/swrla.owl#isRuleEnabled> "true"^^xsd:boolean) Annotation(rdfs:comment ""^^xsd:string) Annotation(rdfs:label "S1"^^xsd:string) Body(BuiltInAtom(<http://swrl.stanford.edu/ontologies/built-ins/3.3/swrlx.owl#makeOWLThing> Variable(<new>) Variable(<x>)) ClassAtom(:Test Variable(<x>)))Head(ClassAtom(:Shadow Variable(<new>))))
)

SWRL rules cannot create new individuals, as far as I understand the DL Safe conditions.

In the comments, you linked to an article describing the semantics of that extension:
One of the the first built-ins I implemented provided the ability to create new individuals in a controlled manner. There is a detailed explanation in [2], but basically a built-in called swrlx:makeOWLThing creates a new individual and binds it to its first unbound argument; a new individual is created for each unique pattern of the remaining arguments.
Now, let's take a look at your rule as written in the question:
Test(?x) ^ swrlx:makeOWLThing(?new, ?x) -> Shadow(?new)
If the atoms are processed from left to right, then ?x should be bound when makeOWLThing is encountered, but ?new isn't. That means that you should get a new individuals bound to the variable ?new, and for each value of ?x you should get a different value of ?new. That's what it sounds like you want. However, in the code you posted, I see this:
DLSafeRule(
Annotation(<http://swrl.stanford.edu/ontologies/3.3/swrla.owl#isRuleEnabled> "true"^^xsd:boolean)
Annotation(rdfs:comment ""^^xsd:string)
Annotation(rdfs:label "S1"^^xsd:string)
Body(
BuiltInAtom(<http://swrl.stanford.edu/ontologies/built-ins/3.3/swrlx.owl#makeOWLThing>
Variable(<new>)
Variable(<x>))
ClassAtom(:Test Variable(<x>)))
Head(
ClassAtom(:Shadow Variable(<new>))))
)
I'm not certain, but if that's processed from left to right as well, the makeOWLThing(?new,?x) appears first, in which case ?x would be unbound when the new individual is created, so you'd only get one new individual.

Related

Query on TFP Probabilistic Model

In the TFP tutorial, the model output is Normal distribution. I noted that the output can be replaced by an IndependentNormal layer. In my model, the y_true is binary class. Therefore, I used an IndependentBernoulli layer instead of IndependentNormal layer.
After building the model, I found that it has two output parameters. It doesn't make sense to me since Bernoulli distribution has one parameter only. Do you know what went wrong?
# Define the prior weight distribution as Normal of mean=0 and stddev=1.
# Note that, in this example, the we prior distribution is not trainable,
# as we fix its parameters.
def prior(kernel_size, bias_size, dtype=None):
n = kernel_size + bias_size
prior_model = Sequential([
tfpl.DistributionLambda(
lambda t: tfd.MultivariateNormalDiag(loc=tf.zeros(n), scale_diag=tf.ones(n))
)
])
return prior_model
# Define variational posterior weight distribution as multivariate Gaussian.
# Note that the learnable parameters for this distribution are the means,
# variances, and covariances.
def posterior(kernel_size, bias_size, dtype=None):
n = kernel_size + bias_size
posterior_model = Sequential([
tfpl.VariableLayer(tfpl.MultivariateNormalTriL.params_size(n), dtype=dtype),
tfpl.MultivariateNormalTriL(n)
])
return posterior_model
# Create a probabilistic DL model
model = Sequential([
tfpl.DenseVariational(units=16,
input_shape=(6,),
make_prior_fn=prior,
make_posterior_fn=posterior,
kl_weight=1/X_train.shape[0],
activation='relu'),
tfpl.DenseVariational(units=16,
make_prior_fn=prior,
make_posterior_fn=posterior,
kl_weight=1/X_train.shape[0],
activation='sigmoid'),
tfpl.DenseVariational(units=tfpl.IndependentBernoulli.params_size(1),
make_prior_fn=prior,
make_posterior_fn=posterior,
kl_weight=1/X_train.shape[0]),
tfpl.IndependentBernoulli(1, convert_to_tensor_fn=tfd.Bernoulli.logits)
])
model.summary()
screenshot of the results executed the codes on Google Colab
I agree the summary display is confusing but I think this is an artifact of the way tfp layers are implemented to interact with keras. During normal operation, there will only be one return value from a DistributionLambda layer. But in some contexts (that I don't fully grok) DistributionLambda.call may return both a distribution and a side-result. I think the summary plumbing triggers this for some reason, so it looks like there are 2 outputs, but there will practically only be one. Try calling your model object on X_train, and you'll see you get a single distribution out (its type is actually something called TensorCoercible, which is a wrapper around a distribution that lets you pass it into tf ops that call tf.convert_to_tensor -- the resulting value for that op will be the result of calling your convert_to_tensor_fn on the enclosed distribution).
In summary, your distribution layer is fine but the summary is confusing. It could probably be fixed; I'm not keras-knowledgeable enough to opine on how hard it would be.
Side note: you can omit the event_shape=1 parameter -- the default value is (), or "scalar", which will behave the same.
HTH!

How to infer an object property based on data properties?

I'm a protégé newbie and did the pizza tutorial and read the 101 documentation. I'm trying to model a ontology like the following picture:
I have a person who has a style. The style can be a style_active or style_passive.
This style is determined by a index of two data properties:
ind_passive and ind_active, the bigger value should infer the style.
I had to create two individuals: style_active and style_passive, because they must be individuals to be assigned to the object property has_style.
How to infer the value of has_style object property based on ind_passive and ind_active data properties? Using a reasoner?
Is something wrong with this model?
I suceed in calculate the value of style object property based on two swrl rules. It does not work with a reasoner like HermiT (default in Protégé 5.5), but works in SWRLTab, that uses Drools.
The rules I used:
Name: Passive
Rule: Person(?p) ^ ind_passive(?p, ?ip) ^ ind_active(?p, ?ia) ^ swrlb:greaterThan(?ip, ?ia) -> has_style(?p, style_passive)
Name: Active
Rule: Person(?p) ^ ind_passive(?p, ?ip) ^ ind_active(?p, ?ia) ^ swrlb:greaterThan(?ia, ?ip) -> has_style(?p, style_active)
The reasoner Hermit could not be enabled after using this rules, because it does not supports "built-in atoms", like swrlb:greaterThan.

Limit Array to multiple specific data types

I am working on refactoring a tool to OOP in PS5.
I have a number of classes. Sets can contain other Sets as well as Packages. Packages can contain other Packages and Tasks. And Tasks can contain other Tasks. For example...
Set1
Package1.1
Task1.1
Set2
Package2.1
Task2.1
Set2A
Package2A
Task2A.1
Task2A.2
Package2.2
Task2.2
Set3
Package3.1
Task3.1
Task3.1A
I plan to have Set, Package and Task classes, but there are a number of different Tasks with some common features and some unique, so I will have a base Task class that is then extended by the various final task classes.
My question relates to the data structure to contain the nested objects. If each class could only contain the next deeper type everything would be easy; the variable to hold the Packages in a Set could be an array of Packages, i.e. [Package[]]$Contents.
I could make it super flexible and just do an array; [Array]$Contents, but that allows for invalid items like strings and such.
Alternatively I could have some sort of Root class, with Sets, Packages and Tasks all extended that, and final Tasks then extending Tasks, and use[Root[]]$Contents or some such. But that might not be possible and it would still allow for adding a Task to a Set, since a final Task class would ultimately be extending from Root.
So, the question becomes, can you define an array that accepts multiple possible types but is still limited, something like [Set/Package[]]$Contents? Or is there perhaps a totally different way to define a variable that limits the valid members? An Enum seems to have potential, but it seems like they are limited to strings as I tried
enum AllowedTypes {
[Array]
[Strings]
}
and that in no good.
Or am I best of just using an Array and validating what I am adding in the Add method of each Class? I can see a possible solution there where I have overloaded Add methods in the Set class, one that takes a Set, one that takes a Package, and one that takes a generic object and throws an error to log. Assuming that the more specific overload method takes priority rather than everything going to the generic method since it's technically valid. Or perhaps that generic method won't even work since the collection of overloaded Add methods technically can't collapse to one valid choice because a Set is both a [Set] and a [PSObject] I guess.
PetSerAl, as countless times before, has provided an excellent (uncommented) solution in a comment on the question, without coming back to post that solution as an answer.
Given the limits of code formatting in comments, it's worth presenting the solution in a more readable format; additionally, it has been streamlined, modularized, extended, and commented:
In short: a PowerShell custom class (PSv5+) is used to subclass standard type [System.Collections.ObjectModel.Collection[object]] in order to limit adding elements to a list of permitted types passed to the constructor.
class MyCollection : System.Collections.ObjectModel.Collection[object] {
# The types an instance of this collection
# is permitted to store instance of, initialized via the constructor.
[Type[]] $permittedTypes
# The only constructor, to which the permitted types must be passed.
MyCollection([Type[]] $permittedTypes) { $this.permittedTypes = $permittedTypes }
# Helper method to determine if a given object is of a permitted type.
[bool] IsOfPermittedType([object] $item) {
return $this.permittedTypes.Where({ $item -is $_ }, 'First')
}
# Hidden helper method for ensuring that an item about to be inserted / added
# / set is of a permissible type; throws an exception, if not.
hidden AssertIsOfPermittedType([object] $item) {
if (-not $this.IsOfPermittedType($item)) {
Throw "Type not permitted: $($item.GetType().FullName)"
}
}
# Override the base class' .InsertItem() method to add type checking.
# Since the original method is protected, we mark it as hidden.
# Note that the .Add() and .Insert() methods don't need overriding, because they
# are implemented via this method.
hidden InsertItem([int] $index, [object] $item) {
$this.AssertIsOfPermittedType($item)
([System.Collections.ObjectModel.Collection[object]] $this).InsertItem($index, $item)
}
# Override the base class' SetItem() method to add type checking.
# Since the original method is protected, we mark it as hidden.
# This method is implicitly called when indexing ([...]) is used.
hidden SetItem([int] $index, [object] $item) {
$this.AssertIsOfPermittedType($item)
([System.Collections.ObjectModel.Collection[object]] $this).SetItem($index, $item)
}
# Note: Since the *removal* methods (.Remove(), .RemoveAt())
# need to type checking, there is no need to override them.
}
With the above class defined, here's sample code that exercises it:
# Create an instance of the custom collection type, passing integers and strings
# as the only permitted types.
# Note the (...) around the type arguments, because they must be passed
# as a *single argument* that is an *array*.
# Without the inner (...) PowerShell would try to pass them as *individual arguments*.
$myColl = [MyCollection]::new(([int], [string]))
# OK, add an [int]
# .Add() implicitly calls the overridden .InsertItem() method.
$myColl.Add(1)
$myColl.Add('hi') # OK, add a [string]
# OK, override the 1st element with a different [int]
# (though a [string] would work too).
# This implicitly calls the overridden .SetItem() method.
$myColl[0] = 2
# OK - insert a [string] item at index 0
$myColl.Insert(0, 'first')
# $myColl now contains: 'first', 2, 'hi'
# Try to add an impermissible type:
$myColl.Add([long] 42)
# -> Statement-terminating error:
# 'Exception calling "Add" with "1" argument(s): "Type not permitted: System.Int64"'

OWL-API: making a set of individuals equivalent to owl:Thing

I'm trying to add an equivalent axiom of the following form:
owl:Thing EquivalentTo {individual1, indivdual2, ... individualN}
Below is how I'm trying to add the axiom:
String individualSet = "{a, b, c, d}"
OWLAxiom a = df.getOWLEquivalentClassesAxiom(df.getOWLClass(individualSet), df.getOWLThing());
manager.addAxiom(ontology, a);
The problem is that this actually creates an extra class with the name "{a, b, c, d}", which prevents a reasoner from making right conclusions as intended.
In Protege, I can add this type of Equivalent To axiom without resulting in an extra class... How can I do the same with OWL-API?
I figured it out. I had to use OWLObjectOneOf to compose a set of individuals and make that equivalent to owl:Thing.

Is it possible to define a multi valued DataProperty in OWL2 specifying the different values it should take for a given case?

Im regenerating an ontology to OWL2 using the OWL-API and testing with Protégé.
There are some concepts that are subclass of many superclasses, and some DataProperties that should take multiple values, for example:
Artifactual Location & Artifactual Area
And I want to specify that:
• For Artifactual Location the DataProperty hasConcreteEntityType should take the values LOCATION and ARTIFACT
• For Artifactual Area the DataProperty hasConcreteEntityType should take the values ARTIFACTUAL_LOCATION and AREA
Class Tree & Class Descriptions
But after activating the reasoner, I get Artifactual Location misclassified to Nothing(but not both)
Inference Explanations
And I don't understand what's wrong with the inference explanation,but seems that there should be a third explanation like the second but related to the value AREA, so seems that doesn't support bi-valued properties like this, or, maybe there is another way to define and constraint the values of a multi-valued DataProperty or even the reasoner doesn't work fine with this,
im using Hermit 1.3.8.3
Quoting the comment on my previous answer (I've deleted the answer because it is incorrect)
[The ontology] should be here drive.google.com/file/d/0B2FYMQD3DD8DNWtteUlLcDgyTGM/ Look at the linguisticUnitType property for Morphosyntactic Unit, as I defined it (to have 2 values, MORPHOLOGICAL and SYNTACTIC) it is classified fine by the reasoner, but it doesn't behave the same with the properties hasConcreteEntityType and hasLocationType regarding the classes at Nothing Artifactual Area and Artifactual Location. I don't understand why for one case is fine but not for the other, because the properties and restrictions are defined in the same manner.
The problem is that Artifactual Area is defined as subclass of Location, which already restricts the values of hasConcreteType to only one value (LOCATION). In order to allow Artifactual Area to have exactly two values, the restriction on the superclass must be removed or amended.
For future reference, the fragment in Functional syntax is here:
Ontology(<http://localhost/pruebaLUO.owl>
DataPropertyDomain(:hasConcreteEntityType :ConcreteEntity)
DataPropertyRange(:hasConcreteEntityType DataOneOf("ARTIFACT"^^xsd:string "FOOD"^^xsd:string "LIVING_ENTITY"^^xsd:string "LOCATION"^^xsd:string "MATERIAL"^^xsd:string "ORGANIC_OBJECT"^^xsd:string "PHYSICAL_OBJECT"^^xsd:string "SUBSTANCE"^^xsd:string))
DataPropertyDomain(:hasLocationType :Location)
DataPropertyRange(:hasLocationType DataOneOf("3D"^^xsd:string "AREA"^^xsd:string "ARTIFACTUAL_LOCATION"^^xsd:string "GEOPOLITICAL"^^xsd:string "OPENING"^^xsd:string "OTHER"^^xsd:string))
DataPropertyDomain(:linguisticUnitType :LinguisticUnit)
DataPropertyRange(:linguisticUnitType DataOneOf("MORPHOLOGICAL"^^xsd:string "SEMANTIC"^^xsd:string "SYNTACTIC"^^xsd:string))
AnnotationAssertion(rdfs:label :Area "Area"#en)
SubClassOf(:Area :Location)
SubClassOf(:Area DataHasValue(:hasLocationType "AREA"^^xsd:string))
AnnotationAssertion(rdfs:label :Artifact "Artifact"#en)
SubClassOf(:Artifact :ConcreteEntity)
SubClassOf(:Artifact DataHasValue(:hasConcreteEntityType "ARTIFACT"^^xsd:string))
SubClassOf(:ArtifactualArea :Area)
SubClassOf(:ArtifactualArea :ArtifactualLocation)
SubClassOf(:ArtifactualArea DataExactCardinality(2 :hasLocationType DataOneOf("AREA"^^xsd:string "ARTIFACTUAL_ LOCATION"^^xsd:string)))
SubClassOf(:ArtifactualLocation :Artifact)
SubClassOf(:ArtifactualLocation :Location)
SubClassOf(:ArtifactualLocation DataHasValue(:hasLocationType "ARTIFACTUAL_ LOCATION"^^xsd:string))
SubClassOf(:ArtifactualLocation DataExactCardinality(2 :hasConcreteEntityType DataOneOf("ARTIFACT"^^xsd:string "LOCATION"^^xsd:string)))
SubClassOf(:Building :ArtifactualLocation)
SubClassOf(:ConcreteEntity :GenericEntity)
SubClassOf(:Entity :PropositionalComponent)
SubClassOf(:GenericEntity :Entity)
SubClassOf(:Location :ConcreteEntity)
SubClassOf(:Location DataHasValue(:hasConcreteEntityType "LOCATION"^^xsd:string))
SubClassOf(:MorphologicalUnit :LinguisticUnit)
SubClassOf(:MorphologicalUnit DataHasValue(:linguisticUnitType "MORPHOLOGICAL"^^xsd:string))
SubClassOf(:MorphosyntacticUnit :MorphologicalUnit)
SubClassOf(:MorphosyntacticUnit :Token)
SubClassOf(:MorphosyntacticUnit DataExactCardinality(2 :linguisticUnitType DataOneOf("MORPHOLOGICAL"^^xsd:string "SYNTACTIC"^^xsd:string)))
SubClassOf(:PropositionalComponent :SemanticUnit)
SubClassOf(:SemanticUnit :LinguisticUnit)
SubClassOf(:SemanticUnit DataHasValue(:linguisticUnitType "SEMANTIC"^^xsd:string))
SubClassOf(:SyntacticUnit :LinguisticUnit)
SubClassOf(:SyntacticUnit DataHasValue(:linguisticUnitType "SYNTACTIC"^^xsd:string))
SubClassOf(:Token :SyntacticUnit)
)

Resources