RE: [icom] Agreement on a model?

[Eric Chan <eric-s.chan@oracle.com>]

Hello Patrick,

Currently, there is an ambiguity about the boundaries between ICOM, Beehive, Ecospace, and SIOC model. We need to emphasize that ICOM is not an agglomeration of vocabularies from Beehive, Ecospace, and SIOC namespaces, but rather a coherent collection of concepts in a new namespace and a versatile framework to relate the concepts. My intention for the ballot was for the TC to formally approve the use of ICOM namespace to demarcate the starting or working draft model and any new concepts we introduce into ICOM. It was not meant to fix the model or framework at this early stage. Certainly, the model or framework should be allowed to evolve freely to accommodate all anticipated use cases.

Regards,
Eric

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Thursday, October 29, 2009 6:09 AM
To: icom@lists.oasis-open.org
Subject: [icom] Agreement on a model?

Greetings!

Apologies but it seems to me that there isn't a common understanding of 
what it would mean to "agree on a model" in the TC.

As Deirdre said yesterday, we can agree on the necessary components 
without necessarily agreeing on how to model those components. (Deirdre, 
correct me if I am incorrect in saying that, but that was my impression.)

Eric, on the other hand, I think wants agreement not only on the 
components but also on the modeling of those components as shown at: 
http://wiki.oasis-open.org/icom/Categorisation

But, Eric says that is a starting point for further work.

1) It isn't clear to me if we "approve" a model, what does it mean as "a 
starting point for further work?" Does that mean that we cannot change 
the components or modeling that we approved but can add things to it?

2) If "approving a model" does not fix certain aspects of the model, 
then why ask the TC to "approve" the model?

3) If the purpose of the model is to have a uniform "measure" that can 
be put up against use cases to see if we are capturing everything in the 
model that is needed, that hardly requires a vote of the TC to "approve" 
the model. We simply agree this is the model to use for discussions 
until at some point we decide that we need to add or subtract from it 
and then we will have a new "measure" to use in our discussions.

BTW, Eric's point that in OO you have to have a framework into which to 
place parts of the model is true but the framework should not be beyond 
discussion. After all, what we are discussing *is* a framework.

Granted we all discuss components with some vague framework in mind and 
having a model helps focus our discussion by making the framework 
explicit, but that should not be seen as placing the model beyond 
discussion.

Hope everyone is having a great day!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php