Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Plugs, sockets, connectors and compatibility #236

Closed
areleu opened this issue Apr 18, 2024 · 2 comments
Closed

Plugs, sockets, connectors and compatibility #236

areleu opened this issue Apr 18, 2024 · 2 comments

Comments

@areleu
Copy link

areleu commented Apr 18, 2024

Hi, I have been following your work for a while now. And based on your ontology I am developing https://github.com/dlr-ve-esy/charging-ontology/ which handles terminology of electric vehicle charging infrastructure.

One of the things that has got pretty interesting during the development is the inclusion of connecting components. By connecting components I mean Plugs, Sockets, Cables, Connectors and such. In the context of electric vehicles this is important becasue it dictates if some vehicle is able to charge in certain charging station. Some older ideas around the topic I discuss in: dlr-ve-esy/charging-ontology#2 and OpenEnergyPlatform/ontology#1597 . The reason I raise the issue here is because that I noticed very quickly that there are some aspects of this that I think would be more valuable when handled in a general context that ontologies like yours can offer.

When researching the topic I got down a very deep rabbit hole, connectors are weird constructs to be honest. I came up with the implementation at dlr-ve-esy/charging-ontology#4 but I am not 100% confident of it, so please feel free to give feedback on it. Here is a summary of the implementation

Implementation

connector: Fiat object part of some device providing connection and disconnection to a suitable mating component.

plug: A connector attached to a cable.
outlet: A connector attached to the surface of a device.

connection pattern: A pattern of connectors which is the physical manifestation of some specification that dictates its mating suitability.

power connection specification: A directive information entity that prescribes the requirements of power connectors.

'power connection specification' prescribes some 'connection pattern'

'connector' 'bearer of' some 'connection pattern'

These would be an example of the multiple connector classes that I implemented:
CHAdeMO specification a power connection specification

'CHAdeMO pattern' 'prescribed by' value 'CHAdeMO specification'

Open questions

Would terminology of connectors fit into one of the CCOs?

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

How does one express "compatibility" in BFO, maybe using relational quality?

@cameronmore
Copy link
Contributor

Thank you for the comments and research on this topic!

I'll make some comments on your proposed definitions and then some some general suggestions.

Definitions

Although it seems like a fiat object part of a longer cable, connectors would be their own 'Material Artifact.' A Fiat object part would be an arbitrary part of a cable, but the place where the connector begins and cable ends seems more bona fide than fiat. Also, connectors can be built and sold on their own, without a cable at all, like electric connectors for iPhones and power adapters for building wall sockets. A connector may be part of a cable, but it is not necessary.

Also, I would clarify that you mean electric connector, as opposed to other types of connectors for plumbing, for example.

A convention we use in creating definitions for Artifacts is to define the artifact in terms of the function that the artifact was designed for. So, an electronic connector is a material artifact designed to allow for the flow of electronic power between other artifacts? Just a start, not a final.

'Genders' and styles of electronic connectors are similar to car body types in that they come in a wide range of varieties and there may be special, one-off, or hybrid types that are routinely invented/created, just something to keep in mind. My initial impression is that these types are fiat object parts of connectors, since you can't have a connector without it being of such and such type. Every connector has a type, but the connector itself isn't just the type (the prongs, for example), so it seems like each connector has part some electronic connector pattern.

The connection patterns are material types, not specifically dependent continuants. We might colloquially say that a power connector 'bears' some type, but it's really got an instance of a type as a part, steering me toward fiat object part.

I'm not sure what requirements that a power connection specification prescribes. The requirements of the device that is using the power ('This device needs AAA batteries)? Or the power connector type, like prong or jack?

Open Questions

We would be happy to include 'electronic connectors' as a top level term, but I (personally) think that a full, nuanced representation should belong in a domain extension ontology build off of CCO. The purpose of the CCO is to cover a wide array of everyday entities--as opposed to medically and biologically relevant entities--so developers may have clear guidance on how to represent a special domain and be compatible with other ontologies that also use the Common Core. Your work here seems very relevant to the Industrial Ontologies Foundry (https://github.com/iofoundry/ontology), and they might be very receptive to including your work as an extension module. However, there may be plans to unify our communities and align together, so perhaps it is best to wait on committing. The IOF and CCO diverged a few years ago, so many of the things I said here would still be relevant for including your ontology there. Recently, a paper was written describing a 'maintenance' module that extends IOF, and your project seems similar in its place in a wider industrial ecosystem (https://arxiv.org/abs/2404.05224).

Also, if we were to fully acquire the representation of electronic connectors, it might slow the development of the domain since we are not specialists and do not have a primary interest in its full representation, as you might.

At first, Relational Quality seems like a good place for compatibility, but it seems like a very generic term that could either be narrowed or include new subclasses. Since one of the examples of relational quality is compatibility, it might be often mistaken for compatibility of personality. Perhaps 'Mechanical Compatibility' would be better. The other option is to say that there is a measurement, and that compatibility holds between two connectors which have been measured to be complimentary, though this starts to really get in the weeds, and one may have to start listing a large number of common connector types and which other types they are compatible with... which feeds into my opinion that the full representation of this idea should be in a domain extension (but I am open to other opinions).

@oliviahobai
Copy link
Contributor

Moving to discussion for further development

@CommonCoreOntology CommonCoreOntology locked and limited conversation to collaborators Aug 7, 2024
@oliviahobai oliviahobai converted this issue into discussion #346 Aug 7, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants