I am writing a SWRL rule in OWL which can infer if a person is of driving age or not.
Person(?p), xsd:int[>= "18"^^xsd:int <= "65"^^xsd:int](?age), hasAge(?p, ?age) -> isDriverAge(?p, "True"xsd:Boolean)
It gives me Unexpected Character '[' error
I saw similar syntax for Object Property (found here: https://dior.ics.muni.cz/~makub/owl/ ) but that is also not working when I tweaked my ontology as per this code:
Person(?p), int[>= 18 , <= 65](?age), hasAge(?p, ?age) -> hasDriverAge(?p, True)
If you know the answer, could you please also provide me a resource which I can refer to write these rules. I don't want to keep coming back to stack and eat up other dev's time. Thanks
Related
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.
Connected to this question (and its previous ones):
Using sh:maxExclusive to compare (the values of) two datatype properties
I created a small ontology with three classes: DataSubject, MemberState, and Minor. There are two datatype properties: has-age and has-minimalage. The former is from DataSubject(s) to integers, the latter is from MemberState(s) to integers. Then there is an object property has-member-state from DataSubject(s) to MemberState(s).
Now we have the following individuals:
ontology:John
rdf:type ontology:DataSubject ;
ontology:has-age "20"^^xsd:positiveInteger ;
ontology:has-member-state ontology:Spain ;
.
ontology:Spain
rdf:type ontology:MemberState ;
ontology:has-minimalage "16"^^xsd:positiveInteger ;
.
And I want to write a SHACL rule saying that each DataSubject whose age is less than the minimal age of his member state is also an individual of the class Minor.
In light of the replies I got to my other questions, I tried:
sh:rule [
rdf:type sh:TripleRule ;
sh:condition [
sh:property [
sh:path ontology:has-age ;
sh:lessThan (ontology:has-member-state ontology:has-minimalage)
] ;
] ;
sh:subject sh:this ;
sh:predicate rdf:type;
sh:object ontology:Minor ;
] ;
Which does not work: it classifies John as Minor, but 20 is not less than 16. Of course I tried many other variants, e.g., "sh:lessThan[sh:node[sh:path (ontology:has-member-state ontology:has-minimalage)];];", many of which do not probably make any sense, but none of them work.
Can someone suggest me how to embed a path in the parameter of sh:lessThan?
I am sorry if I start being annoying with all these questions :-( I am new to SHACL and SPARQL but I am really trying my best to learn them out of all what I can find on the Web.
Thanks
Livio
The official spec is (hopefully) pretty clear that the values must be IRIs, i.e. only direct properties are permitted. You can however try to revert the logic and use a path at the property shape. Otherwise, fall back to SPARQL.
I'm trying to implement a rule that substract 1 years to a datetime and asign it to a data property using only SWRL
I've got an entity Product which got a data property creationDate equal to 2019-07-15T00:00:00.
My SWRL rule is the following :
Product(?p) ^ creationDate(?p, ?cd) ^ swrlb:yearMonthDuration(?dur, 1, 0)
^ swrlb:subtractYearMonthDurationFromDateTime(?result, ?cd, ?dur)
-> Product(?p) ^ yearBeforeCreation(?p, ?result)
I expect to get yearBeforeCreation equal to 2018-07-15T00:00:00
Right now I've tried the SWRL with Pellet and Drools
Thanks for your help !
I manage to make my SWRL work, look like it was something with protege. I've close/open, rewrite my rule and it work.
Reading through https://docs.perl6.org/language/packages#Package-qualified_names it outlines qualifying package variables with this syntax:
Foo::Bar::<$quux>; #..as an alternative to Foo::Bar::quux;
For reference the package structure used as the example in the document is:
class Foo {
sub zape () { say "zipi" }
class Bar {
method baz () { return 'Þor is mighty' }
our &zape = { "zipi" }; #this is the variable I want to resolve
our $quux = 42;
}
}
The same page states this style of qualification doesn't work to access &zape in the Foo::Bar package listed above:
(This does not work with the &zape variable)
Yet, if I try:
Foo::Bar::<&zape>; # instead of &Foo::Bar::zape;
it is resolves just fine.
Have I misinterpreted the document or completely missed the point being made? What would be the logic behind it 'not working' with code reference variables vs a scalar for example?
I'm not aware of differences, but Foo::Bar::<&zape> can also be modified to use {} instead of <>, which then can be used with something other than literals, like this:
my $name = '&zape';
Foo::Bar::{$name}()
or
my $name = 'zape';
&Foo::Bar::{$name}()
JJ and Moritz have provided useful answers.
This nanswer is a whole nother ball of wax. I've written and discarded several nanswers to your question over the last few days. None have been very useful. I'm not sure this is either but I've decided I've finally got a first version of something worth publishing, regardless of its current usefulness.
In this first installment my nanswer is just a series of observations and questions. I also hope to add an explanation of my observations based on what I glean from spelunking the compiler's code to understand what we see. (For now I've just written up the start of that process as the second half of this nanswer.)
Differences (if any) between Package::<&var> vs &Package::var?
They're fundamentally different syntax. They're not fully interchangeable in where you can write them. They result in different evaluations. Their result can be different things.
Let's step thru lots of variations drawing out the differences.
say Package::<&var>; # compile-time error: Undeclared name: Package
So, forget the ::<...> bit for a moment. P6 is looking at that Package bit and demanding that it be an already declared name. That seems simple enough.
say &Package::var; # (Any)
Quite a difference! For some reason, for this second syntax, P6 has no problem with those two arbitrary names (Package and var) not having been declared. Who knows what it's doing with the &. And why is it (Any) and not (Callable) or Nil?
Let's try declaring these things. First:
my Package::<&var> = { 42 } # compile-time error: Type 'Package' is not declared
OK. But if we declare Package things don't really improve:
package Package {}
my Package::<&var> = { 42 } # compile-time error: Malformed my
OK, start with a clean slate again, without the package declaration. What about the other syntax?:
my &Package::var = { 42 }
Yay. P6 accepts this code. Now, for the next few lines we'll assume the declaration above. What about:
say &Package::var(); # 42
\o/ So can we use the other syntax?:
say Package::<&var>(); # compile-time error: Undeclared name: Package
Nope. It seems like the my didn't declare a Package with a &var in it. Maybe it declared a &Package::var, where the :: just happens to be part of the name but isn't about packages? P6 supports a bunch of "pseudo" packages. One of them is LEXICAL:
say LEXICAL::; # PseudoStash.new(... &Package::var => (Callable) ...
Bingo. Or is it?
say LEXICAL::<&Package::var>(); # Cannot invoke this object
# (REPR: Uninstantiable; Callable)
What happened to our { 42 }?
Hmm. Let's start from a clean slate and create &Package::var in a completely different way:
package Package { our sub var { 99 } }
say &Package::var(); # 99
say Package::<&var>(); # 99
Wow. Now, assuming those lines above and trying to add more:
my Package::<&var> = { 42 } # Compile-time error: Malformed my
That was to be expected given our previous attempt above. What about:
my &Package::var = { 42 } # Cannot modify an immutable Sub (&var)
Is it all making sense now? ;)
Spelunking the compiler code, checking the grammar
1 I spent a long time trying to work out what the deal really is before looking at the source code of the Rakudo compiler. This is a footnote covering my initial compiler spelunking. I hope to continue it tomorrow and turn this nanswer into an answer this weekend.
The good news is it's just P6 code -- most of Rakudo is written in P6.
The bad news is knowing where to look. You might see the doc directory and then the compiler overview. But then you'll notice the overview doc has barely been touched since 2010! Don't bother. Perhaps Andrew Shitov's "internals" posts will help orient you? Moving on...
In this case what I am interested in is understanding the precise nature of the Package::<&var> and &Package::var forms of syntax. When I type "syntax" into GH's repo search field the second file listed is the Perl 6 Grammar. Bingo.
Now comes the ugly news. The Perl 6 Grammar file is 6K LOC and looks super intimidating. But I find it all makes sense when I keep my cool.
Next, I'm wondering what to search for on the page. :: nets 600+ matches. Hmm. ::< is just 1, but it is in an error message. But in what? In token morename. Looking at that I can see it's likely not relevant. But the '::' near the start of the token is just the ticket. Searching the page for '::' yields 10 matches. The first 4 (from the start of the file) are more error messages. The next two are in the above morename token. 4 matches left.
The next one appears a quarter way thru token term:sym<name>. A "name". .oO ( Undeclared name: Package So maybe this is relevant? )
Next, token typename. A "typename". .oO ( Type 'Package' is not declared So maybe this is relevant too? )
token methodop. Definitely not relevant.
Finally token infix:sym<?? !!>. Nope.
There are no differences between Package::<&var> and &Package::var.
package Foo { our $var = "Bar" };
say $Foo::var === Foo::<$var>; # OUTPUT: «True»
Ditto for subs (of course):
package Foo { our &zape = { "Bar" } };
say &Foo::zape === Foo::<&zape>;# OUTPUT: «True»
What the documentation (somewhat confusingly) is trying to say is that package-scope variables can only be accessed if declared using our. There are two zapes, one of them has got lexical scope (subs get lexical scope by default), so you can't access that one. I have raised this issue in the doc repo and will try to fix it as soon as possible.
if x->a and y-> b
then
from x->a == xy-->ay [ir2] xy-->a [ir4]
from y->b == xy-->xb [ir2] xy-->b [ir4]
therefore xy-->ab [ir5]
But elmasri navathe says , x-->a and y-->b DOES NOT IMPLY xy-->ab
i am just starting with functional dependency , so could some one point out what i am missing ?
Although my knowledge on functional dependencies is not complete at all, I do not see any mistakes in your way of thoughs.
Could you provide an excerpt of the text?
I found a copy of the book I guess you are referring to online: http://cecfoces.files.wordpress.com/2010/09/elmasri-navathe-fundamentals-of-database-systems-3rd-ed1.pdf
Could you please indicate where they say x-->a and y-->b DOES NOT IMPLY xy-->ab?
I just checked C J DATE , where in chapter 11 , page 339 it lists a rule called composition , if a->b , c->d then ac->bd , so that answers part of my query but am curious as to why it says otherwise in navathe .