|
"Chicken,
chicken chicken chicken. Chicken?" :))
It
makes sense and even has a value: 1,256,418 - Chickens?
:)
BTW
how many chickens exist (or may exist, or eated, or will be eated, or whatever
regarding the chicks)?
Yuri
----- Original Message -----
Sent: Tuesday, February 07, 2012 5:24
PM
Subject: Re: [ontology-summit] OS-2012
Problem Space
An example of information loss is available
at:
--- http://www.youtube.com/watch?v=yL_-1d9OSdk
Just
replace the work chicken with system, chickens with systems and you should get
the picture real fast.....
Have fun,
Joe
On Tue, Feb 7, 2012 at 1:25 PM, Ali SH <asaegyn+out@xxxxxxxxx>
wrote:
Dear Jack,
Also this reference might help elucidate the notion of patterns in this
context [1], specifically section 4.
[1] GUIZZARDI, Giancarlo ; FALBO, R. A. ; PEREIRA FILHO, José Gonçalves
. Using Objects and Patterns to Implement Domain Ontologies. Journal of the
Brazilian Computer Society, Brasil, v. 8, n. 1, p. 43-56, 2002. - http://www.loa.istc.cnr.it/Guizzardi/SBES2001vf.pdf
Best,
Ali
On Tue, Feb 7, 2012 at 3:40 PM, Ali SH <asaegyn+out@xxxxxxxxx> wrote:
Dear Jack,
On Tue, Feb 7, 2012 at 2:45 PM, Jack Ring <jring7@xxxxxxxxx> wrote:
Why not start by showing us the
similarities and differences among modeling, analysis, problem,
codification and transformation.
Then was heist 'patterns'?
I definitely do not follow re "heist patterns".
I'm not sure I understand. Are you asking how modeling, analysis,
problems etc. are all similar and/or different? At a high level, one
identifies a problem, analyses it, models it, perhaps codifies said model
in a particular language, and if they need to communicate with others,
then perhaps provide a transformation of said codification to another. Not
necessarily a linear activity, but easy to conceptualize as
such.
Obviously, they are all connected to one another.
My interpretation of these terms is that a problem pattern pertains
to descriptions of commonly occurring issues with regards to various
aspects of systems. I would suggest that the problem themes in Exhibit 3
in [1] could all be candidate problem patterns.
An analysis pattern might then refer to different ways of
characterizing how the problem can be addressed in the systems context. It
would refers to the methodologies, perspectives or other that are useful
in analyzing the domain. Though it need not to, it could take as input
problem patterns and produce analyses of the problems as they apply to
different systems contexts.
A modeling pattern would refer to particular commitments for the
domain description. These patterns might take as input analysis patterns,
and provide as output suggestions / possible ways of modeling the analysis
- whether in natural language, FOL, category theory, but a way of
ontologizing aspects of the analysis. For example, formalizing
/ articulating the notion of "component" as a particular set of axioms
could be a possible modeling pattern.
The distinction between modeling and codification patterns is a bit
less clear to me, though perhaps Giancarlo can clarify his intent with
these terms. Hazarding a guess, I suspect that a codification pattern take
as input a modeling pattern, and produce as output a representation of
said pattern in a specific coding scheme / language. Though I am not happy
with this treatment. But say the modeling pattern suggested that a 3D
design choice was useful for characterizing the notion of role. The
codification pattern would take this 3D design choice and explicate how it
would be represented in say, CommonLogic or OWL...
So let's take the notion of roles. MatthewWest presented a use case
which I believe contained a problem pattern for the role of roles within a
systems appilcation. This spawned a series of discussions regarding how to
treat roles, each perspective contributing an analysis pattern of varying
quality. Some further discussions elaborated on this analysis and went so
far as to tie it to an upper ontology or ways of formally representing
roles in an ontology - these would be modeling patterns. Finally, though
we haven't quite gotten there, perhaps someone would suggest how to
incorporate such a modeling pattern into SysML or formalize it as a set of
Common Logic axioms -- these would be the codification patterns.
Finally, perhaps we want to demonstrate how the notion of Role as
formalized and codified in SysML can be mapped to roles as they are used
in another modeling paradigm. Such an output would be a transformation
pattern.
Is this clear?
Best,
Ali
-- (•`'·.¸(`'·.¸(•)¸.·'´)¸.·'´•) .,.,
-- (•`'·.¸(`'·.¸(•)¸.·'´)¸.·'´•) .,.,
_________________________________________________________________
Msg
Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe:
mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community
Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community
Portal: http://ontolog.cim3.net/wiki/
--
Joe Simpson
Sent From My DROID!!
_________________________________________________________________
Msg
Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community
Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community Portal: http://ontolog.cim3.net/wiki/
|