Replies: 2 comments
-
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. DefinitionsAlthough 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 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 Open QuestionsWe 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). |
Beta Was this translation helpful? Give feedback.
-
Moving to discussion for further development |
Beta Was this translation helpful? Give feedback.
-
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
apower 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?
Beta Was this translation helpful? Give feedback.
All reactions