This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
AmHome
>
ArchMgmtMeetings
>
ArchMgmtMeetings20120216
(16 Feb 2012,
JimConallen
)
(raw view)
Date: *16 Feburary 2012* <br />Time: 7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 8:30 PM Bangalore<br />Call In Number: (emailed)<br />Participation request: contact JimConallen ---++ Agenda 1 Review minutes from last meeting 1 Updates on Core Activities 1 Common properties/types discussion * [[AMResPropertiesV3][Common OSLC AM Resource Properties]] * [[AMResTypesV3][Common OSLC AM Resource Types]] ---++ Attendance Regrets: John Crouchley Atendees: Vishy Ramaswamy, Clyde D Icuspit, Jim Conallen ---++ Minutes In the OSLC AM domain resources are incredibly varied. There is no fixed set of properties (literal or relations) that apply to all resources in this domain. When performing impact analysis it isn't all that clear which references indicate an impact and which do not.<br /><br />One approach is to list and identify properties that can be defined for resource types. With a full enough listing of properties an impact engine could determine when one resources changes, which related resources are also impacted.<br /><br />Looking at the OSLC CM specification as an exemplar of a vocabulary, we saw many relations of the form: * relatedChangeRequest * relatedTestCase * relatedTestExecutionRecord * relatedTestPlan * relatedTestScript where there was a verb, and some expectation of the type of resource on the target end. We can interpret this to mean an expectation that the resource on the target end of the link is a specific type. Or we can interpret this to mean that from the source resource's point of view it considers the target one of those types.<br /><br />There was some concern over so many types of predicates that all basically mean the same thing, but with different expectations of the type of resource on the other end. We all agreed that we would rather have one predicate (i.e. related ) and get the target type directly from the resource.<br /><br />We also noticed another pattern with predicates like: * affectedByDefect * affectsPlanItem How the predicate is worded directly affects the impact analysis. For example, if A is affectedByDefect B, then any change in B will impact A, however the reverse is indeterminant. This means that if the target of the relationship changes then the source is impacted.<br /><br />On the other had with a relationship like A affectsPlanItem B. If B changes it does not imply A is impacted, however if A changes then B is impacted. Or if the source of the relationship changes the target is impacted.<br /><br />It would be nice if all relationships were consistent (i.e. if the target changes the source is impacted), however we can not garantee this.<br /><br />After some discussion we came up with the following: 1 In general the default 'impact determiniation' of a relationship is that if the target changes, it impacts the source resource. If the source changes, it is undetermined if the target is affected. 1 If this is not the case then ontology writers should explicitly indicate that which direction impact is felt (i.e. both, neither, target to source, or source to target). We will investigate any existing RDFS or OWL mechanisms that do this. This was a good discussion, and we hope the rest of the team will contribute via the email list.<br /><br /><br />
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r2 - 16 Feb 2012 - 20:07:30 -
JimConallen
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback