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

Telescope and Microscope subclass of Camera? #239

Open
alanruttenberg opened this issue Apr 22, 2024 · 7 comments
Open

Telescope and Microscope subclass of Camera? #239

alanruttenberg opened this issue Apr 22, 2024 · 7 comments

Comments

@alanruttenberg
Copy link

It looks like telescope and microscope both satisfy the definition of camera and so would be subclasses. Currently they are siblings.

@cameronmore
Copy link
Contributor

I see how it could be interpreted this way, but the operative parts of the definitions are distinct.

Cameras record while microscopes enable users to see and telescopes aid in observation. I think the emphasis should be read on record here, and this could be added as a clarifying annotation.

Unless this is not a convincing interpretation.

@alanruttenberg
Copy link
Author

The problem is that some telescopes and microscopes are built to record. The telescopes I deal with in my domain are built to record - they are cameras that happen to have telescope lens structure. So there will be multiple inheritance. This needs to be better factored. There is the optics aspect, what kind of lens or mirror is used, and there is a separate aspect which is whether they are used to record or not. All things with lens/mirrors in optical systems share some properties, such as focal length. Imaging sensors have a distinct set of properties (spectral sensitivity, detector size, detector technology).

Off the top of my head, there should probably be a function realized in recording an image, and make camera defined in terms of that function. The spectral range should also be factored out into a relationship so they can be used in defined classes, and those can be re-used for optical filters - there's only Filter in CCO, but I will need to represent optical filters of various sorts. There's another multiple inheritance issue. An optical filter would be both an optical instrument and Filter. Filter is again the sort of class that should be a defined class defined in terms of a function. Also notice that there are parallel subclasses Infrared camera and infrared telescopes, and nothing that links them both as being sensitive to infrared.

By defined class I mean a class that has an equivalentClasses axioms as part of their definition.

@alanruttenberg
Copy link
Author

Also note the definition of the parent 'imaging instrument': A Material Artifact that is designed to produce images (visual representations) of an entity.

A visual representation is an information entity. If a telescope merely helps you see something by focusing light, that's not producing an representation or image. To be a representation is more than just perceiving what is there.

@cameronmore
Copy link
Contributor

cameronmore commented Apr 26, 2024

That's a good point; it seems to produce material entities which bear representative ICEs. I think 'produce' is fine because it does produce but may not record (like a camera). It seems to me that imagining instruments and their subclasses create concretizations using light, and those concretizations bear information which represents entities that interact with that light.

But this might not be accurate because the light isn't 'captured' in a simple telescope, but just concentrated so as to let the light hit your eye (or a camera) in a particular way.

@alanruttenberg
Copy link
Author

But this might not be accurate because the light isn't 'captured' in a simple telescope, but just concentrated so as to let the light hit your eye (or a camera) in a particular way.

Right. Unless you consider the pattern of activation of your vision cells or brain as concretization, which is pushing it. There's also a difference between a screen that has a concretization, like your phone's camera constantly displaying whats in front of it on a screen, vs what happens which you tap to take an image and it is saved to nonvolatile storage. Another example of that is a ground glass screen on which some telescopes project.

But more importantly this needs to factored better. The focusing element is mix and match with whether there is a sensor making a recording or not. Sensors will have a hierarchy and focusing elements will have a hierarchy and they will be combined using defined classes of artifacts that have both as parts, with a specific function.

@cameronmore
Copy link
Contributor

Alan, can we work on refactoring both this and the optical lenses at the same time? Offline perhaps until we have something concrete?

@alanruttenberg
Copy link
Author

Yes that makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants