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

CQ 1.3: A charging point is compatible with some plugs #2

Open
areleu opened this issue Apr 2, 2024 · 5 comments
Open

CQ 1.3: A charging point is compatible with some plugs #2

areleu opened this issue Apr 2, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@areleu
Copy link
Collaborator

areleu commented Apr 2, 2024

Plugs and sockets

Summary

We need an implementation that deals with OpenEnergyPlatform/ontology#1597

The solution is not trivial since connections are a weird construct. I really think there is a higher order concept that should be defined in an ontology such as the CCO but for matter of scope we will constraint this application to electrical plugs.

Current status

What we have so far is the general structure: connector with its sub-classes plug and socket which I consider are fiat object parts of some other component/device.

For definitions sources I have:

Both are pretty restrictive in their terms of usage, I am not taking their definitions as they are but I would like to offer some mappings where I consider suitable, is inspiration considered fair use?

Then there is the connection types. My idea is to implement something like connection pattern that should be the quality inherent to the particular objects. This pattern then should be associated to its respective specification using the appropriate is about relation. After that is where it gets weird, should I then implement a bunch of specification instances that can then be used as range of different connection pattern classes? or is it better to associate the connection patterns per device instance? (Reminder: link this issue in CCO when the repository is open)

@areleu areleu self-assigned this Apr 2, 2024
@areleu areleu added the enhancement New feature or request label Apr 2, 2024
@areleu areleu added this to the Release 1.0.0 milestone Apr 2, 2024
@areleu
Copy link
Collaborator Author

areleu commented Apr 11, 2024

Question: "Is it necessary to double the connection pattern(qualities) for male and female, or can the pattern refer to both types of connectors?"

@areleu
Copy link
Collaborator Author

areleu commented Apr 12, 2024

We need to figure out how to addres the association between charging modes and connectors, if that is ever necessary.

@areleu
Copy link
Collaborator Author

areleu commented Apr 12, 2024

How does one express "compatibility" in BFO?

@areleu
Copy link
Collaborator Author

areleu commented Jul 2, 2024

Try to articulate how our model can deal with openchargemap/ocm-system#131

@areleu
Copy link
Collaborator Author

areleu commented Jan 21, 2025

TODO: add all the sockets of the ConnectorType in https://github.com/ocpi/ocpi/blob/master/releases/OCPI-2.2.pdf

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

No branches or pull requests

1 participant