Re: [icom] Agreement on a model?

[Patrick Durusau <patrick@durusau.net>]

Eric,

Eric Chan wrote:
> 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.
>
>   
Ah, ok, so let me say it back:

A TC vote will be to approve the use of the ICOM namespace as a means to 
distinguish "ICOM" concepts from concepts found in other models.

But isn't that the role of namespaces already?

I understand the need to distinguish ICOM from other vocabularies but 
however "different" we view our work to be from that of others, that 
isn't the same thing as others viewing ICOM as different.

Even at this early stage if there are some core concepts or properties 
associated with them that cure problems or issues with other 
vocabularies, that would be one way to distinguish ICOM. Granted that a 
namespace makes it a unique space but there are lots of those.

What would make ICOM attractive is for it to be a unique space that 
*offers advantages* over other extant vocabularies.

Those advantages could be rooted in the concepts chosen to anchor the 
work, the modeling of those concepts, or even in their extensibility.

Hope you are having a great day!

Patrick
> 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)