In DL (and OWL-DL): Given a TBox, two concepts C1 and C2, in my problem, we say that a path exists between C1 and C2 if and only if:
C1 ⊑ =1 r.C2 where r is a single/composite role (role chain)
i.e. if r is a single role then we must have each instance of C1 related to exactly one instance of C2 through r; otherwise (r is composite) then each instance of C1 is related to exactly one instance of C2 through a composition of roles i.e. (r1*r2*r3...) if we consider * stands for role composition.
My question is: Is the Graph sense the best way to accomplish this task using OWL API, where graph nodes stand for concepts and edges stand for object properties. Then we start from C1 node and perform a breadth-first search until we reach C2. This is my idea! Is there any better way to perform this?
This problem is generally about fining paths which have specific characteristics between two ontology concepts. For the ease of understaning, you can eliminate the exactly one restriction. Thus
C1 ⊑ ∃ r.C2
Related
I have following structure
One organization can have many environments.
One environment can have many Applications.
One application can have many Policis.
I created class of each entities i.e.
class Organization,
class Environment,
class Application,
class Policy
Now I want to apply policies to Application.
One policy should have one Policy class object. All instances of Policy are different. Every policy have unique name and ID.
Inheritance will not work, Consider following hierarchy -
Organization
Environment(Organization)
API(Environment)
Policy(API)
because every policy, required to procide all details of API, Environment, Organization.
Can we do aggregation here? Need help on this
All instances of Policy are different.
Every policy have unique name and ID
You can indicate that with the constraint :
Policy.allInstances() -> forAll(p1, p2 |
p1 <> p2 implies (p1.name <> p2.name and p1.ID <> p2.ID))
A class diagram from the information you give can be :
I do not use bidirectional relations supposing Policy does not know the associated Application(s) whose does not know associated Environment(s) whose does not know associated Organization(s).
I use multiplicities * equivalent to 0..* because nothing in your question says the minimum multiplicity is 1 each time. I do not indicate the multiplicity in the opposite direction of the relations because your question does not indicate something about them.
Inheritance will not work
A inherits B implies A is a B, among the classes your give none of them satisfy that, so there is no possible inheritance between them.
Can we do aggregation here
may be between Environment and Application because we can say an environment is composed by applications, but else where no.
I have the following graph model to represent a microservice architecture
(:Team {space})-[:OPEX]->(:Service)-[:USES]->[:Service]
a Team belongs to a space (a department)
a Team has operation ownership (=OPEX) over several Services
Services have USES relationships between them
My query in natural language:
find all the Teams in a certain space, and via the OPEX relationship find all their Services
also include all USES relationships between these services in the result
I'm having problems expressing this query in an elegant Cypher query. I came up with the following, but there must be an easier and more natural way to express it.
MATCH (t1:Team {space:"shopping"})-[o1:OPEX]->(s1:Service),
(t2:Team {space:"shopping"})-[o2:OPEX]->(s2:Service),
(s3:Service)-[u:USES]->(s4:Service)
WHERE s3.name=s1.name AND s4.name=s2.name
RETURN t1, o1, s1, u, s2, o2, t2
Can someone point me into a better direction?
You should reuse variables that refer to the same instance, and you can use IN and COLLECT to find patterns in a set of nodes.
Something like this
MATCH (:Team {space:"shopping"})-[:OPEX]->(s:Service)
WITH COLLECT(s) as services
MATCH (t:Team {space:"shopping"})-[o:OPEX]->(s1:Service)
OPTIONAL MATCH (s1:Service)-[u:USES]->(s2:Service)
WHERE s1 in services AND s2 in services
RETURN t, o, s1, u, s2
I came across this term called database closure.
I tried to look for it and what exactly it means but I have not found any simple explanation.
Can someone please explain what the concept of closure is and specifically what is a database closure, if it is good /bad, how it can be used or avoided ?
Also seems like there is in general a closure term: http://en.wikipedia.org/wiki/Closure_%28computer_science%29 which relates to binding of variables to function. Is a database closure related to this ?
Thanks!
Closure is actually a relatively simple concept. When designing databases we want to know that our database tables have as little redundancy as possible. This means making sure that we can have as little relationships between sets (or tables) as possible.
An example:
If we have two sets X and Y (which you can think of as two tables called X and Y) and they have a relationship with each other as so:
X -> Y (Read this as Y is dependent on X)
And we have another set Z which is dependent on Y:
Y -> Z (also read as Y determines Z)
To find the closure we find the minimum number of tables that we can reach all relationships with. In this case all we need is X.
So now, when we design our database we know that we only have to have a relationship from X, and Z and Y can actually be derived from X. We can therefore make sure there are no extra relationships in our database which cause redundancy.
If you want to read more, closure is a part of a topic called normalisation.
Closure is mentioned in database theory / set theory discussions -- as in, Dr. Codd / design & normalization kind of stuff. It has to do with finding the minimally representational elements of sets (i.e., without redundancy, etc.). I tried reading-up on it a long time ago, but my eyes went crossed, and I got a really bad headache.
If you want to read a decent summary of closure, here is one: http://www.cs.sfu.ca/CC/354/jpei/slides/ClosureDecomposition.pdf
All operations are performed on an entire relation and result in an entire relation, a concept known as closure. And that is one of relational database systems characteristics
The closure is essentially the full set of attributes that can be determined from a set of known attributes, for a given database, using its functional dependencies.
Formal math definition:
Given a set of functional dependencies, F, and a set of attributes X. The closure is defined to be the set of attributes Y such that X -> Y follows from F.
Algorithm definition:
Closure(X, F)
1 INITIALIZE V:= X
2 WHILE there is a Y -> Z in F such that:
- Y is contained in V and
- Z is not contained in V
3 DO add Z to V
4 RETURN V
It can be shown that the two definition coincide.
A database closure might refer to the closure of all of the database attributes. According to the definitions above, this closure would be the set of all attributes of the database itself.
The closure (computer science) term that you linked to is not related to closure in databases but the mathematical closure is.
For a better understanding of functional dependencies and a simple example for closure in databases I suggest reading this.
If we are referring to Closure in the Functional Dependency sense (relating to database design),
The closure of a set F of functional dependencies is the set of all functional dependencies logically implied by F.
The minimal representation of sets is referred to as the canonical cover: the irreducible set of FD's that describe the closure.
I have some confusion with applying Larman's system operation contracts (OO Analysis from book Applying UML and Patterns) on CRUD-like operations. More precisely, I'm confused with postcondition part.
For example, if I have CRUD system operations looking as follows:
createEmployee(employee:Employee),
readEmployee(employeeId:int),
updateEmployee(employee:Employee),
deleteEmployee(employeeId:int)
what would be postcondition on, for example, readEmployee system operation, or some other operation like searchEmployees etc?
For example: for read operation, system needs to read record from database, instantiate domain object, set attribute values on domain object (set relations also) and that's it. Does it means that postconditions are above mentioned - instance creation, changes on attributes, etc. Or, read operation does not have any postcondition. None of this does sound logical to me.
My confusion is about relation between domain model (state) and database (state). I just don't get implications which above operations will have on domain model. I always think in way that the database is a place that preserves the state of the system. After I create employee, its object's state will be persisted in database... But what happens with domain model state?
The post-condition defines what the state of your application (or object, depending on the level of abstraction) should be after the operation for it to be considered as successful. For the readEmployee operation, for example, the post-condition would be that:
a new Employee instance is created.
the Employee instance contains attributes matching the database values.
the database connection is closed.
I like to think of "pre-condition" and "post-condition" as the "state of mind" of your application before and after an operation has executed, respectively. As you can imagine, it's more a thought process than a coding exercise when you do DbC.
(If you do unit-testing, states make it clear what needs to be covered by your tests. Basically, you end up testing the "state of mind" of your application.)
Interestingly, if you consider the reverse of DbC, you realise that to identify what operations your application (or object) should expose, it is simply a matter of listing what states it can have and how it transitions between these states. The actions that you need to take to make these transitions then become your operations, and you do not have to bother with implementing operations that do not lead to any desired states. So, for example, you probably want the following states for your application.
Employee details added (S1)
Employee details loaded (S2)
Employee details updated (S3)
Employee details deleted (S4)
The following state transitions are possible.
S1 -> S3 (add new employee, update the details)
S1 -> S4 (add new employee, delete the employee)
S2 -> S3 (load employee details, update employee details)
S2 -> S4 (load employee details, delete employee)
S4 -> S1 (delete employee, add new employee)
S2 -> S1 (load employee details, add new employee)
S3 -> S1 (update employee details, add new employee)
S3 -> S2 (update employee details, load employee details)
Based on the above, you can write your operations in such a way that only valid transitions are allowed, with anything else giving rise to errors.
Impossible state transitions:
S4 -> S2 (cannot delete an employee, then load their details)
S4 -> S3 (cannot delete an employee, then update their details)
State modeling is probably the most important part of designing objects, so you're asking the right questions. If you want a good resource on state modeling, get Object Lifecycles Modeling the World in States from Sally Shlaer / Stephen Mellor. It is quite an old book and costs almost nothing on Amazon, but the principles it introduces form the basis of modern UML -- incidentally, the notation used in the book looks nothing like UML.
I realise I did not touch on database state, but at the conceptual level, the database layer is just another system of states and the same principles apply.
I hope this was useful.
My interpretation of Larman's contracts is always with respect to the domain model. Larman clearly states there are only 5 types of post conditions:
Instance creation
Instance deletion
Attribute change of value.
Associations formed.
Associations broken.
Therefore, a Read (or search) operation would have no post conditions, at least not on the elements that are being read or searched. For example, if 10,000 users performed reads/searches in one day, but never did any of the other operations (C, U, D), there would be no change to the objects in the domain.
There is an exception to this, however, in domains where searches/reads are remembered. For example, Google surely keeps track of searches. In this case, doing a search has the postcondition of creating a new object in their domain model, e.g., A Search instance s was created (instance creation).
The confusing comes form mentioning data model relation within the contract template that Larman provided as in :
Contract CO2: enterItem
Operation: enterItem(itemID : ItemID, quantity : integer)
...
sli was associated with a ProductSpecification, based on itemID match (association formed).
The detail referential properties of the database should not be mentioned in the operation contract. It is better to leave it as: "sli was associated with a ProductSpecification".
In fact, it is one of the things that Larman's operation contracts does not talk about in much detail. Think about a contract for an operation that calculates a total number of items and return the total ! seems that it cannot be written as an operation contract.
I've been trying to encode a relational algebra in Scala (which to my knowlege has one of the most advanced type systems) and just don't seem to find a way to get where I want.
As I'm not that experienced with the academic field of programming language design I don't really know what feature to look for.
So what language features would be needed, and what language has those features, to implement a statically verified relational algebra?
Some of the requirements:
A Tuple is a function mapping names from a statically defined set of valid names for the tuple in question to values of the type specified by the name. Lets call this name-type set the domain.
A Relation is a Set of Tuples with the same domain such that the range of any tuple is uniqe in the Set
So far the model can eaisly be modeled in Scala simply by
trait Tuple
trait Relation[T<Tuple] extends Set[T]
The vals, vars and defs in Tuple is the name-type set defined above. But there should'n be two defs in Tuple with the same name. Also vars and impure defs should probably be restricted too.
Now for the tricky part:
A join of two relations is a relation where the domain of the tuples is the union of the domains from the operands tuples. Such that only tuples having the same ranges for the intersection of their domains is kept.
def join(r1:Relation[T1],r2:Relation[T2]):Relation[T1 with T2]
should do the trick.
A projection of a Relation is a Relation where the domain of the tuples is a subset of the operands tuples domain.
def project[T2](r:Relation[T],?1):Relation[T2>:T]
This is where I'm not sure if it's even possible to find a sollution. What do you think? What language features are needed to define project?
Implied above offcourse is that the API has to be usable. Layers and layers of boilerplate is not acceptable.
What your asking for is to be able to structurally define a type as the difference of two other types (the original relation and the projection definition). I honestly can't think of any language which would allow you to do that. Types can be structurally cumulative (A with B) since A with B is a structural sub-type of both A and B. However, if you think about it, a type operation A less B would actually be a supertype of A, rather than a sub-type. You're asking for an arbitrary, contravariant typing relation on naturally covariant types. It hasn't even been proven that sort of thing is sound with nominal existential types, much less structural declaration-point types.
I've worked on this sort of modeling before, and the route I took was to constraint projections to one of three domains: P == T, P == {F} where F in T, P == {$_1} where $_1 anonymous. The first is where the projection is equivalent to the input type, meaning it is a no-op (SELECT *). The second is saying that the projection is a single field contained within the input type. The third is the tricky one. It is saying that you are allowing the declaration of some anonymous type $_1 which has no static relationship to the input type. Presumably it will consist of fields which delegate to the input type, but we can't enforce that. This is roughly the strategy that LINQ takes.
Sorry I couldn't be more helpful. I wish it were possible to do what you're asking, it would open up a lot of very neat possibilities.
I think I have settled on just using the normal facilities for mapping collection for the project part. The client just specify a function [T<:Tuple](t:T) => P
With some java trickery to get to the class of P I should be able to use reflection to implement the query logic.
For the join I'll probably use DynamicProxy to implement the mapping function.
As a bonus I might be able to get the API to be usable with Scalas special for-syntax.