I want to add a restriction for height (data property) of a Person (class) such that height can't be <= 0.
Is there a data range / inequality value restriction in owl like:
height only xsd:decimal[">0"^^xsd:decimal]
As I understand, we have some xsd:minInclusive and xsd:maxExclusive conditions but unfortunately I don't know how to use it, in OWL reasoning.
Related
I would like to combine the result of some predictive models by weighting their results. In the most related works the weights of models are in the range of (0,1),But I have found that negative weights result in better prediction.So, at first, I set the lower bound to -3 and upper bound to 7. In additionو I have to determine a constraint on the sum of the weights of the models and the best result has been achieved by the constraint of 1.
Does it make sense to determine the weights like what I mentioned?
I have a relation
R
-------
cid sid gradepoint credits
CS425 001 4.0 3
I need to calculate the GPA. There are more rows, but I believe if I just get this answered I should be ok with the rest. I need to do gradepoint * credits. How do I express this with a relational algebra expression?
My best guess is:
, but I'm not sure if I can multiply attributes with anything other than a constant.
Relational algebra doesn't address domain-specific operations. It neither includes nor excludes it, just like real algebra neither includes nor excludes operations on relations.
If you allow multiplication by constants, you're already combining algebras (which is pretty much required for any practical application) so I see no reason to disallow multiplication between attributes.
Notice that if expressions like you are using are allowed then it is projection that is doing the multiplying. Instead of its inputs being a relation value & attribute names, its inputs are a relation value and expressions of some sort that include names of operators whose inputs are values of attribute types. Your projection is parsing and multiplying. So it is a different operator than one that only accepts attribute names.
The projection that takes attribute expressions begs the question of its implementation given an algebra with projection only on a relation value and attribute names. This is important in an academic setting because a question may be wanting you to actually figure out how to do that, or because the difficulty of a question is dependent on the operators available. So find out what algebra you are supposed to use.
We can introduce an operator on attribute values when we only have basic relation operators taking attribute names and relation values. Each such operator can be associated with a relation value that has an attribute for each operand and an attribute for the result. The relation holds the tuples where the result value is equal to the the result of the operator called on the operand values. (The result is functionally dependent on the operands.)
So suppose we have the following table value Times holding tuples where left * right = result:
left right result
-------------------
0 0 0
1 0 0
...
0 1 0
1 1 1
2 1 2
...
If your calculated attribute is result then you want
/* tuples where for some credits & gradepoint,
course cid's student sid earned grade gradepoint and credits credits
and credits * gradepoint = result
*/
project cid, sid, result (
R natural join (rename left\credits right\gradepoint (Times))
)
Relational algebra - recode column values
PS re algebra vs language: What is a reference to the "relational algebra" you are using? There are many. They even have different notions of what a "relation" is. Some so-called "algebras" are really languages because the expressions don't only represent the results of operators being called on values. Although it is possible for an algebra to have operand values that represent expressions and/or relation values that contain names for themselves.
PS re separation of concerns: You haven't said what the attribute name of the multiplication result is. If you're expecting it to be credit * gradepoint then you're also expecting projection to map expression-valued inputs to attribute names. Except you are expecting credit * gradepoint to be recognized as an expression with two attribute names & and an operator name in one place but to be just one attribute name in another. There are solutions for these things in language design, eg in SQL optional quotes specialized for attribute names. But maybe you can see why simple things like an algebra operating on just attribute names & relation values with unique, unordered attribute names helps us understand in terms of self-contained chunks.
What is the proper way to implement following thing:
Task: query documents where voltage (float) equals 100.0 and tolerance -0% / +20%.
q=+voltage_f[100.0 TO 120.0]
I want that documents with the voltage near to lower bound (100.0) get more points as the documents with the voltage near upper bound (120.0).
Or vice versa - tolerance -20% / +0%.
q=+voltage_f[80.0 TO 100.0]
I want that documents with the voltage near to upper bound (100.0) get more points as the documents with the voltage near lower bound (80.0).
You can use the recip function to get a value that starts at 1 and then tapers off as the value increases:
Performs a reciprocal function with recip(x,m,a,b) implementing a/(m*x+b) where m,a,b are constants, and x is any arbitrarily complex function.
When a and b are equal, and x>=0, this function has a maximum value of 1 that drops as x increases. Increasing the value of a and b together results in a movement of the entire function to a flatter part of the curve. These properties can make this an ideal function for boosting more recent documents when x is rord(datefield).
For your first case, that could be implemented by using recip directly, and adjusting the a and b values to suit your needs.
For the second case you can use abs(sub(100, x)) as x, as that becomes larger as the value is further away from 100.
The recip call can be added in bf (for dismax, edismax) or in boost (edismax).
Your frontend will have to decide the proper values to use for a, b or m - you can use debugQuery=true to see how much the boost contributes and adjust accordingly.
How I can add to cube calculations (New Calculated Measure) which based on another calculated measure? Simply referencing to this name, gives me NULL (I don't get error). After changing to different measure I get correct value.
Measure 1:
[Measures].[A] + [Measures].[B] - [Measures].[C]
Measure 2:
AGGREGATE(NULL:TAIL(EXISTING [Date].[Date].[Date].Members).Item(0), [Measures].[Measure 1])
Use the calculation from your first calculated measure and add to it to build the calculation for your new calculated measure.
EDIT:
As an example of what I mean, say you have [measures].[CalcMeasure1]
that has a calculation (definition) of [measures].[measure_A] + [measures].[measure_B]
And you wanted to create [measures].[CalcMeasure2] that adds measure_C to CalcMeasure1, you would give it a definition of:
[measures].[measure_A] + [measures].[measure_B] + [measures].[measure_C]
So to use the code from your question, your Measure 2 would be:
AGGREGATE(NULL:TAIL(EXISTING [Date].[Date].[Date].Members).Item(0), ([Measures].[A] + [Measures].[B] - [Measures].[C]))
According to MSDN:
Expression: Specify the expression that produces the values of the
calculated member. This expression can be written in Multidimensional
Expressions (MDX). The expression can contain any of the following:
•Data expressions that represent cube components such as dimensions,
levels, measures, and so on
•Arithmetic operators
•Numbers
•Functions
You can drag or copy cube components from the Metadata tab of the
Calculation Tools pane to quickly add them to an expression.
Any calculated member that is to be used in the value expression of
another calculated member must be created before the calculated member
that uses it.
I have two questions :
(1) The function getOWLDatatypeMinInclusiveRestriction (and similarily for MaxInclusive, (min, max) exclusive) for constraining facets
for the datatype accept as input only double or integer values.
Is that means that facets restrictions with OWL API cannot be applied for decimals.
(2) How can I get the datatype of a dataTypeProperty by OWL API?
1) the methods you mention are shorthand for (perceived) most common uses. You can create the same restrictions with decimals but you'll have to create the literals and combine them manually. I don't have an example at hand but can add one later if you need.
2) look for data property range axioms on that property.