Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should I be surprised to see Magenta and its fellows listed as subclasses of color rather than reference data instances? #287

Open
ericatail opened this issue Jun 28, 2024 · 6 comments
Assignees
Labels
for 2.1 release These are changes we would like to see addressed under the 2.1 release

Comments

@ericatail
Copy link

Should I be surprised to see Magenta and its fellows listed as subclasses of Color rather than reference data instances?

Thanks!

@swartik
Copy link

swartik commented Jun 28, 2024

Well, two distinct independent continuants would not bear the same magenta color individual. Each would bear a separate color so you could associate both the independent continuant and the color with a process individual. You would then use that process individual to record when it was observed that the individual was magenta, who made the observation, etc.

There are other considerations. You might have each Color individual concretize a measurement information content entity (MICE) to describe the wavelength range of the color. In this formulation, a green color has a wavelength between 495-570 nm (according to Wikipedia). You could use that to make assertions about the MICE a Color subclass concretizes.

But as in all uses of ontology, the real answer to your question is: what do you want to model?

@ericatail
Copy link
Author

ericatail commented Jun 29, 2024

Thanks for your reply.

If colors were pure single-frequency EM radiation, then we might give them EM frequency intervals and be done with it.
But many are, of course, superimposed waveforms.

But a EM sensor could give us a pure green frequency in some cases. And a verbal narative that we perform entity extraction on would parse the word "green" and might instantiate a shared Green instance with your standard green interval.

But my customer isn't giving me any color sensor data, So to answer your question, the latter case is what I want to model.

I apologize, I can't stop thinking of that interval green case or the simple Magenta color token as an instance. Green would be a shared instance with an attached freq. interval. that everyone would use - I call that shared reference data - like the name shared instance John.
So would independent continuants actually need to bear their own color individuals? I didn't follow why processes come into the discussion. I'm not sure why the process couldn't just reference a shared individual color. But I'm rather new to CCO.

Thanks!
-Eric

@ericatail
Copy link
Author

To my mind, the very fact that we are discussing frequency ranges, superimposed wave forms and such means that we need an instance to hang such data off of.

And it seems inefficient to have multiple instances of your cco:Green when one instance of cco:Color will do. Sorry if I'm missing something obvious.

@ericatail
Copy link
Author

ref:Green a cco:Color .

@cameronmore
Copy link
Contributor

cameronmore commented Jun 30, 2024

There are different ways of understanding this. Unlike measurement units, which are shared reference data (we all point to the same 'Meter' when measuring), green and other colors are instances of dispositions, and so each instance of color you encounter is going to be a unique, different instance of a disposition. Just as two people who weigh 150lbs do not weigh the same 150lbs, they are different instances of weight but the measurement of their weight may have the same literal value.

Another way to think about green as a disposition; green is a color, and a color is a phenomenon consisting of hue, saturation, and brightness of how light behaves. Green is just a subset of all those instances of colors which have a particular hue/brightness/saturation that namely arises 'in the visible spectrum, typically between 520 to 560 nanometers.' Instances of colors are always instances of colors on this visual spectrum, and these subclasses are approximate attempts to group those instances in terms of our ability to differentiate them.

Or, to put it another way, it is true that the green in one tree is not the same in another tree, but what is the same is that they are both particular, different instances of cco:Colors with a certain similarity based on their hue/brightness/saturation, being in the same portion of the light spectrum.

I'm happy to work through this issue, please let me know if I am not capturing your concern, thank you, Cameron

@ericatail
Copy link
Author

ericatail commented Jul 1, 2024

Hey Cameron!

Thanks for your reply! It's good to bump into you over here.

Maybe I'm too focused on the data I have to work with. I suppose that green could be thought of as a collection of the individual green wavelengths you speak of and I've claimed before that any collection could be declared to be a class (or subclass).

Right now, all my customer needs is the enumerated type green. But since we all want our our modeling to endure changes in our level of sophistication, I modeled it as an instance. When we start to care about wavelengths,, hue, saturation, etc., hanging this data off the subclass Green seems rather odd to my software engineering sensibilities.

But I have bigger fish to fry, I I probably just need to get used to using the subclass Green . It will work as a sort of enumerated type and I would guess that will cover my modest data set needs for the next decade or so.

Thanks again!

-Eric

@neilotte neilotte added the for 2.0 release This label indicates updates to be made in the 2.0 release, which will include a new IRI format. label Aug 18, 2024
@neilotte neilotte added this to the All issues tagged for 2.0 are addressed milestone Aug 19, 2024
@neilotte neilotte added for 2.1 release These are changes we would like to see addressed under the 2.1 release and removed for 2.0 release This label indicates updates to be made in the 2.0 release, which will include a new IRI format. labels Oct 19, 2024
@neilotte neilotte removed this from the All issues tagged for 2.0 are addressed milestone Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for 2.1 release These are changes we would like to see addressed under the 2.1 release
Projects
None yet
Development

No branches or pull requests

5 participants