wiki-archive/twiki/temp-gjr/BDI/SDD/ResolvedTopicGenericStates.txt,v

head	1.8;
access;
symbols;
locks; strict;
comment	@# @;


1.8
date	2009.11.20.02.45.28;	author LeeBelbin;	state Exp;
branches;
next	1.7;

1.7
date	2007.03.06.17.30.00;	author TWikiGuest;	state Exp;
branches;
next	1.6;

1.6
date	2006.05.04.11.26.30;	author GregorHagedorn;	state Exp;
branches;
next	1.5;

1.5
date	2004.06.21.11.30.01;	author GregorHagedorn;	state Exp;
branches;
next	1.4;

1.4
date	2004.05.28.17.24.04;	author GregorHagedorn;	state Exp;
branches;
next	1.3;

1.3
date	2004.03.10.17.13.59;	author BobMorris;	state Exp;
branches;
next	1.2;

1.2
date	2003.12.05.15.54.00;	author GregorHagedorn;	state Exp;
branches;
next	1.1;

1.1
date	2003.12.05.05.38.18;	author BobMorris;	state Exp;
branches;
next	;


desc
@none
@


1.8
log
@none
@
text
@%META:TOPICINFO{author="LeeBelbin" date="1258685128" format="1.1" reprev="1.8" version="1.8"}%
%META:TOPICPARENT{name="ClosedTopicSchemaDiscussionSDD09"}%
---+!! %TOPIC%

(Bob started the topic with:)

My example is from neuroscience: synapses need two characters: <nop>preSynapticCellType and <nop>postSynapticCellType, which must draw their states from the same enumerated set of neuron types. Probably there will be more familiar examples, like shared color values.

The only way to use them as generic or shared states is to put them into the concept tree.

-- Main.BobMorris - 05 Dec 2003
---

In Lisbon we originally had a flat list of sets of generic (= project-wide shared) states. Each set then had to be a) associated with a number of characters, which we had. However, the state sets are also specific to concepts, a thing we were searching for whether to associate it though the use of glossary entries, or by linking them into the available concept trees for properties, methods, and structures. can have named generic state sets in a flat list. We did not have the latter link.

My bathtub idea the morning I left Lisbon was to throw the flat list away and 
put them directly into the concept trees. We had already agreed to try a similar solution for character dependency (no flat list, but only in the concept tree).

Now generic property states would be in property tree (shapes, colors, etc.), types of structures in the structure tree (berry is a kind of fruit), method 
choices (microscope available/not available) in the method tree.

I believe it makes sense, but we need to discuss and criticize it. It definitely looks like overkill when you have very simple examples where you do not really want concept trees for other reasons.

So currently, <nop>GenericStates is in the <nop>ConceptNodes, and Character/Categorical/States/<nop>StateReference is pointing to states defined therein.

Gregor Hagedorn - 05 Dec 2003  

---
We are making <nop>GenericStates named Opaque, Translucent, and Transparent. We do, in fact, find the mechanism a bit of overkill for this, but maybe tolerable. When we start coding, we likely would find that it is easier to have this mechanism collapse to something simple automatically than it is to have to dispatch two different mechanisms based on how flat the set of concepts is.

However, we have a different minor issue, namely ForGenericStatesShouldTheStateTypeBeOnTheStateDefinition? 

%META:TOPICMOVED{by="GregorHagedorn" date="1085765044" from="SDD.GenericStates" to="SDD.ResolvedTopicGenericStates"}%
@


1.7
log
@Added topic name via script
@
text
@d1 2
a4 2
%META:TOPICINFO{author="GregorHagedorn" date="1146741990" format="1.0" version="1.6"}%
%META:TOPICPARENT{name="ClosedTopicSchemaDiscussionSDD09"}%
@


1.6
log
@none
@
text
@d1 2
@


1.5
log
@none
@
text
@d1 30
a30 30
%META:TOPICINFO{author="GregorHagedorn" date="1087817401" format="1.0" version="1.5"}%
%META:TOPICPARENT{name="SchemaDiscussionSDD09"}%
(Bob started the topic with:)

My example is from neuroscience: synapses need two characters: <nop>preSynapticCellType and <nop>postSynapticCellType, which must draw their states from the same enumerated set of neuron types. Probably there will be more familiar examples, like shared color values.

The only way to use them as generic or shared states is to put them into the concept tree.

-- Main.BobMorris - 05 Dec 2003
---

In Lisbon we originally had a flat list of sets of generic (= project-wide shared) states. Each set then had to be a) associated with a number of characters, which we had. However, the state sets are also specific to concepts, a thing we were searching for whether to associate it though the use of glossary entries, or by linking them into the available concept trees for properties, methods, and structures. can have named generic state sets in a flat list. We did not have the latter link.

My bathtub idea the morning I left Lisbon was to throw the flat list away and 
put them directly into the concept trees. We had already agreed to try a similar solution for character dependency (no flat list, but only in the concept tree).

Now generic property states would be in property tree (shapes, colors, etc.), types of structures in the structure tree (berry is a kind of fruit), method 
choices (microscope available/not available) in the method tree.

I believe it makes sense, but we need to discuss and criticize it. It definitely looks like overkill when you have very simple examples where you do not really want concept trees for other reasons.

So currently, <nop>GenericStates is in the <nop>ConceptNodes, and Character/Categorical/States/<nop>StateReference is pointing to states defined therein.

Gregor Hagedorn - 05 Dec 2003  

---
We are making <nop>GenericStates named Opaque, Translucent, and Transparent. We do, in fact, find the mechanism a bit of overkill for this, but maybe tolerable. When we start coding, we likely would find that it is easier to have this mechanism collapse to something simple automatically than it is to have to dispatch two different mechanisms based on how flat the set of concepts is.

However, we have a different minor issue, namely ForGenericStatesShouldTheStateTypeBeOnTheStateDefinition? 

@


1.4
log
@none
@
text
@d1 2
a2 2
%META:TOPICINFO{author="GregorHagedorn" date="1085765044" format="1.0" version="1.4"}%
%META:TOPICPARENT{name="SchemaDiscussion"}%
@


1.3
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="BobMorris" date="1078938839" format="1.0" version="1.3"}%
d31 1
a31 1
%META:TOPICMOVED{by="GregorHagedorn" date="1070639567" from="SDD.SharedStates" to="SDD.GenericStates"}%
@


1.2
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1070639640" format="1.0" version="1.2"}%
d24 7
a30 2
Gregor Hagedorn - 05 Dec 2003	

@


1.1
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="BobMorris" date="1070602698" format="1.0" version="1.1"}%
d3 5
a7 1
Oh, never mind. I answered my own question. But I'm leaving this as a place holder for discussion of Character/Categorical/States/<nop>StateReference in case the primer doesn't cover it. My example is from neuroscience: synapses need two characters: <nop>preSynapticCellType and <nop>postSynapticCellType, which must draw their states from the same enumerated set of neuron types. Probably there will be more familiar examples, like shared color values.
d10 17
@