OWL/Protege: Combining Object Properties with Conjunction - owl

Say I have a class "Adult" and a class "Child" and two object properties "isFatherOf " and "playsMonopolyWith". Suppose I want all fathers who play monopoly with their children. Now I could do a subclass like:
Adult
isFatherOf some Child
playsMonopolyWith some Child
But this isn't quite right since a father who plays monopoly only with other people's children would be included here. What a really want is:
Adult
(isFatherOf and PlaysMonopolyWith) some child
The child that the father plays monopoly with must be the same child that he is the father of.
This gives syntax error. So I'm guessing the description logic doesn't allow this sort of construct? Is there a work around?

In order to describe business logic, it is often preferable to use inference rules instead of OWL logic.
From your example, if you want a class NiceFather for Fathers who playsMonopolyWith their own Child, here is what to do.
Go to "Window" > "Tabs", and check "SWRLTab", then go to the newly created "SWRLTab". Click on the "New" button.
Write the rule you described in your question. The syntax is pretty straightforward.
isFatherOf(?father, ?child) ^ playsMonopolyWith(?father, ?child) -> NiceFather(?father)
Click "Ok" to create the rule, and run the reasoner.
Here is a Gist that you can download and open in Protégé. As you can see Albert is a nice father because he plays Monopoly with his son Albert Jr. Bob, on the other hand, is not a nice father because he plays Monopoly with Albert Jr. instead of his own son Bob Jr. :)

Related

Plantuml. How to create finite state machine diagrams?

I want to create a FSM diagram and wanted to use plantuml for that. I stuck with backward arrows
There is a way to create backward arrows but it looks overcomplicated and too limited for such a simple task
#startuml
:start;
repeat :Ask to enter login;
repeat while(Is name valid?) is (No) not (Yes)
:play game;
#enduml
which gives this
but when you want to implement a little bit more complex logic like:
Ask to enter name
Ask to enter password
On the third failed attempt go back to the (1)
it looks like it's just not possible with plantuml
I don't know if it called State diagram but I took a look on all types of diagrams plantuml supports and it seems to be the fittest one
I would say that an activity diagram works best.
What you described is easy to explain, but complex to display in correct UML, I don't think that's specific to plantuml. Here's how I would express what you said:
#startuml
start
while (App) is (running)
:enter username;
repeat
:enter password;
if (Password correct?) then (yes)
:Play game;
stop
endif
repeat while (Third attempt?) is (no) not (yes)
endwhile (exit)
stop
#enduml
As Jeffrey pointed out, you are more likely thinking in terms of activity diagram, your nodes being the actions that happen and not the states.
If you want a state diagram, you need to shift your mind to the background of your currently identified actions. So in the simplest means, there are two main states in your system:
Let's zoom into the first state, which appears to be more complex and deserve some substates. You have identified an Enter a name action while in the game configuration state. Until this action is completed, the name is not known. Once it is completed, the name will be known, but a validity check needs to be performed. You could express this with the following states:
You'll see that when entering the substate No valid name known, the first things that happens is to ask the name. And once everything is fine, you've finished the sub-state machine and can continue to the new states.
The plantuml code is:
#startuml
state Configuring {
state NameNotKnown as "No valid name known":entry / Ask name
state NameKnown as "Name knwon"
[*] --> NameNotKnown
NameNotKnown --> NameKnown : Name entered
NameKnown --> [*] : Name is valid
NameKnown --> NameNotKnown: Name is invalid
}
[*] --> Configuring
Configuring --> Playing : Launch game
Playing --> [*] : Game over
#enduml
It's worth to mention that you could fine tune this diagram, using entry, exit and do behaviors in each simple state. Moreover, you could simplify my example using guarded transitions, and even behaviours that are expressed at transition level.

GEDCOM compatible file output in C#.NET

I tried to create a simple interface for building a gedcom compatible text file using C#.NET.
I am stuck with proper FAM record creation (I mean, something is logically wrong in my code). I believe that tester.cs has a complete information of grandfather, father, self, spouse, child1, and grandson relationships.
Is is possible to correct the gedcom output, without making significant changes in the tester.cs?
May be you need to fork the entire source code. The software produces gedcom.ged file, which should be loaded in Simple Family Tree 1.32 to see that the gedcom is valid.
Currently, I ended up with the funny and unusual relationships as in the picture.
Grandfather should have married to grandmother, and "self" needs to have a child, giving a grand child to grand father. Gotra's spouse should be null (unmentioned). And like that...
Probably I should fix something in individual.cs.
Your help is kindly expected. PS: I am also working to resolve the issue, and the source code may change a bit. Thanks in advance!

Reuse of sequence diagram parts

I have multiple single sequence diagrams.
most of them have the same initialization and termination sequence.
It is possible to copy this from one file to the other but it would be much better if this part could be declared at a single point. So in case of a change it would not be necessary to change all the diagrams.
Is there a way to do this ?
I tried to comment to JRI's answer but I don't have a high enough reputation.
I found that !include works until you need to include the same file multiple times. I got a solution on a plantuml forum and I can't remember the forum but I do remember the solution. On the second and each additional time you include a file you want to use !include_many.
Yes, you should use a reference fragment to reference the separate initialization / termination sequences:
#startuml
participant Alice
participant Bob
ref over Alice, Bob : initialization
Alice -> Bob : hello
ref over Alice, Bob : termination
#enduml
If you want to show the detail of the re-used parts, rather than abstract them away as a reference block, PlantUML allows you to include files using the !include or !includeurl directives.
The syntax also allows you to import particular blocks of code from an imported file. See http://plantuml.com/preprocessing for details.
#user349062 comment is the correct answer. This was not easy to find, and its not in the documentation: Reference Guide
Using !include_many instead of !include in subsequent pages works, which doesn't make much sense, but there you go.

OWL, adding a property to all instances of a class

I'm looking for a way to add an Object Property to all instances of a given class.
Example Problem:
Let's say I'd define three classes.
Religious_Person
Supreme_Being
Christian a subclass of Religious_Person.
Now I'd like to have an Object property "devotes" which has a domain of Religous_Person and a range of Supreme_Being.
I have three instances of Christian: Marck, Bob and Cathy.
I have one instance of Supreme_Being: God.
Now I'd like to state Marck devotes God, Bob devotes God, and Cathy devotes God. It seems tedious to do this for every instance, so I'd like to express that each instance of the class Christian devotes God by default. Now ofcourse this might be somewhat confusing as from this example it might seem that I'd want each and every Religious_Person to devote to only one Supreme_Being, which is not the case.
Example:
Let's say JackAndJillian is a Religious_Person that devotes both Jack and Jill. So I'd like each instance of JackAndJillian to devote both Jack and Jill (whom would both be instances of Supreme_Being).
It feels to me like "devotes" should be a object property of the class Christian, however this is not possible due to classes not having properties.
I'm using protege to help myself in building an ontology so if there'd be a way I can express this in protege that would be great.
You can use owl:hasValue in a SubClassOf axiom (in Manchester OWL syntax):
Class: Christian
SubClassOf: Religious_Person and devotes value God
There is no concept of default value in OWL. Inference in OWL is monotonic, thus, you cannot remove any statement by adding other statements.

Proper way to organize data models in a MEAN stack application

I am making an MEAN stack app and use Mongoose alongside Mongo. I am struggling with organizing my objects in database. All works as expected but I have a feeling that the way I am doing things is wrong, but can't seem to find any resources on the topic that could help me, thus I hope somebody with some experience can share it with me.
I use Mongoose to create several schemas, and there is one dilemma I am facing, concerning nested objects in MongoDB.
Let's say I have a model that looks like that:
ParentSchema:{
property1:String,
children:[{}]
}
So, property1 is just some string, 'children' is an array that will contain objects of type 'Child' with some other properties, but also another array (f.ex. 'grandchildren:[{]} ), this time with another type of objects (Grandchild).
Child and Grandchild have no schemas and do not exist outside of the Parent, and will most likely be unique to each instance of Parent, so two Parents would not be sharing a Child object.
In my app, I am able to use urls such as '/parent/:id1/Child/:id2/Grandchild/:id3', where 'id1' is an actual id of Parent that Mongo generates, while 'id2' is an index of Child object instance stored in Parents array. The same goes for instances of Grandchildren stored inside Child object.
I was thinking that maybe having separate schemas for all 3 objects, and just saving references to objects is the way to go, like this:
ParentSchema:{
prop1:String,
children:[{type:ObjectId, ref:'Child'}]
}
ChildSchema:{
prop1:String,
granchildren:[{type : ObjectId, ref: 'Grandchild'}]
}
GrandChildSchema:{
prop1:String,
prop2:String
}
..but was unsure, as for me it implies that Child and GrandChild instances would be shared between different parents, however it seems easier to work with.
To sum up, I would like to know is:
which approach should I choose and why: first, second or maybe some other that I do not know about yet.
If I were to choose the second approach, should I create a separate API route for each of the objects?
How would I go about creating then? My wish is for the process to look like so:
Start creating Parent -> start creating first Child -> create some Grandchildren ->
finish creating Child -> start creating second Child -> ... -> finish creating Parent.
I apologize if the question is somehow weird, I will try to clarify as best as I can if required.
I would go with the second approach for a couple of reasons:
Schemas have better readability in my opinion.
They allow for data validation which you lack in the first approach.
Please note the answer below is primarily opinion based.
For the API design:
I think its really up to you as to which paths to expose to the consumer, since you've stated Child and Grandchild do not have the right to exist without a parent - I think your routes are fine as they are.
And finally - your process for creating these entities look fine to me. I would do the same thing myself.

Resources