Date: 2013-02-07 12:26:26
From: genesisonto@gmail.com
Hello,
Do instance definitions have to be linked with parent instance definitions
if inference is needed to pull up sub-class instances when we query on
super class instances.
For instance, if we have a hierarchy for status 'Open' -> 'Waiting for user
input.' If I want instance of 'Waiting for user input' to be included when
querying for issues having 'Open' status, do I need to link the children
with parents using rdfs:subClassOf
*CLASS DEFINITIONS*
1. Issue Definition
JIRA --type--> owl:Class
2. Issue status class hierarchy
WaitingForUserInput --rdfs:subClassOf--> Open --rdfs:subClassOf--> Status
*INSTANCE DEFINITIONS*
3. Issue status instance hierarchy
WaitingForUserInput_instance --rdfs:subClassOf--> Open_instance
--rdfs:subClassOf--> Status_instance
4. Issue instance
JIRA instance --hasStatus--> WaitingForUserInput_instance
I wanted to know if the sub class instances specifically have to be
linked to the parent.
Thanks & regards

asked 03 Apr '13, 12:30

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%


ate: 2013-02-07 22:48:03
From: barry.bishop@ontotext.com
Hello Onto Genesis,
The question is a little confusing, so let me start with the basics.
With any built-in rule-set (apart from 'empty') OWLIM will perform some 
basic reasoning with class hierarchies using a rule like this one:
Id:cax_sco
c1 <rdfs:subClassOf> c2
x <rdf:type> c1
-------------------------------
x <rdf:type> c2
So if you specify that Cat is a sub-class of Mammal then every time you 
declare an instance of Cat, OWLIM will infer that this individual is 
also a member of Mammal.
I see what you are trying to do when modelling jira issues - you kind of 
have a hierarchy of states - but doing it this way is a bit confusing. 
What you are saying is that a jira issue IS-A Status, which is not 
really the case. It is probably best to model this with a property 
called 'status' whose value is one of several instance values (open, 
resolved, closed). WaitingForUserInput sounds like a stage in the 
workflow, which is probably just a separate property 'progress' or 
'stageInWorkflow' that has its own enumerated values.
If you want to keep going with your approach then I suppose you would 
create a hierarchy of classes and just change the membership of the jira 
issue as it transitions between states, e.g.
insert: j1 rdf:type Open
delete: j1 rdf:type Open
insert: j1 rdf:type WaitingForUserInput
delete: j1 rdf:type WaitingForUserInput
insert: j1 rdf:type Open
delete: j1 rdf:type Open
insert: j1 rdf:type Resolved
delete: j1 rdf:type Resolved
insert: j1 rdf:type Closed
Which will allow you execute queries like:
SELECT * { ?issue a Open }
and get all the issues that are members of Open or any status derived 
from Open.
However, I would recommend just using a property for status.
I hope this helps,
barry
link

answered 03 Apr '13, 12:30

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%

Date: 2013-02-08 07:08:35
From: genesisonto@gmail.com
Barry,
This is most helpful.  Appreciate your guidance on this.  I will try out
your suggestions.
Best regards
--G
link

answered 03 Apr '13, 12:30

Discussion-Board-Archive's gravatar image

Discussion-B...
6.1k142160227
accept rate: 30%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×261
×242

Asked: 03 Apr '13, 12:30

Seen: 1,462 times

Last updated: 20 May, 07:59

powered by BitNami OSQA