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 .
Related
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
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 am currently moving a fun-project of mine over to bison/flex as parser and have trouble solving a reduce/reduce conflict:
// https://github.com/X39/yaoosl/blob/master/code-gen/yaoosl.y#L761-L766
ifthen: YST_IF YST_ROUNDO expression code_ifstart YST_ROUNDC codebody code_ifendnoelse
| YST_IF YST_ROUNDO expression code_ifstart YST_ROUNDC ifthen_clsd YST_ELSE code_ifelse ifthen code_ifendelse
;
ifthen_clsd: codebody
| YST_IF YST_ROUNDO expression code_ifstart YST_ROUNDC ifthen_clsd code_ifelse YST_ELSE ifthen_clsd code_ifendelse
;
Note: stuff prefixed with code_ are the mid-actions
Could somebody explain to me how to solve this properly and why the "go-to" solution is either wrong or did not worked?
Thanks, X39
Since the two rules are identical up to the code_ifelse (and assuming code_ifelse is an empty rule, like an in-rule action), it can't tell whether to reduce code_ifelse before or after the YST_ELSE. You might be able to fix it by making the two rules consistent with the order of code_ifelse and YST_ELSE.
Some rules-of-thumb for grammars:
Don't use symblic names for single char tokens like '(' and ')' -- it just obfuscates things and makes the grammar hard to read and understand.
Don't use in-rule actions unless absolutely necessary -- it's better to create a single token rule with an end-rule action that does what you need.
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.
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)
)