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
>
ArchMgmtMeetings15Apr2010
(29 Apr 2010,
JimConallen
)
(raw view)
Date: *15 April 2010* <br />Time: *7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa* <br />Call In Number: (emailed)<br />Participation request: contact JimConallen ---++ Agenda 1 JimConallen will update workgroup of OSLC Core status. 1 Continue to introduce new objectives for 2.0 specificatiom ---++ Minutes Atendees:Thomas Picolli, Jim Amsden, Dave Johnson, Jim Conallen Jim A. gave us some information on the architectural direction that the Object Management Group (OMG) is going. They expect to use a subset of OWL to express modeling concepts.<br /><br />Jim C. asked if we should entertain the the idea of OWL ontologies as a subject for the AM specification. It is something that is most appropriate for archiecture (modeling) resources, as compared to the basic resource management things that are already being addressed in the core specification.<br /><br />Jim A. raised a common concern that we continue to siloed at the business level, and that we have multiple ways of saying the same things. We will always have specific terms for specific domains, so we need a way of saying things synomously.<br /><br />Tom P. agreed that this would be a good extension from the 1.0 specification. But should we adopt a common model [ed: meta-model?] or go with a mapping approach?<br /><br />Jim A. said that we could do both. For each space (i.e. BMPN, SOAML, ..) we capture a common canonical view, and make ontologies for them. But also make mappings between them, allowing it to evolve into a common model. <br /><br />There are two perspectives / dimensions to think about. 1) lifecycle, versioning, etc. This is the OSLC sweet spot. and 2) content of the resources them self as they apply to the AM domain.<br /><br />We still need a common foundation technology on how resources are described, linked to, etc. This is currently being provided by the common core spec.<br /><br />Jim C. suggested that ontologies could be used normalize a set of architecture resources across domains (but for same context), and be used for things like impact analysis, in a domain neutral way.<br /><br />Jim A. offered another approach as a shared semantic grounding. If we could all agree on and build on triples with patterns, and use RDFS to describe patterns.<br /><br />Jim c. added that this might be difficult to do with propriority closed resources, and those that are already built/defined. Tom said that these resources still need to be connected to mapped to a normalized ontology to participate in impact analysis.<br /><br />Dave J. asked how this was any different from the other specifications. Jim C. went on to explain how AM resources could be mapped to defined ontologies that are crafted for things like impact analysis. Each domain (UML, BMPN, ER, SOAML, ...) would map things like relationships to this ontology, which would define properties like "impactable". A generic impact analysis tool would then only need to know about this ontology's properties to do its job.<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 - 29 Apr 2010 - 12:13:55 -
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