`cimex` ontology: decide prefix and prop names

[VladimirAlexiev]

#16 derives a number of new props.
They are defined in https://rawgit2.com/statnett/Talk2PowerSystem/main/demo1/cimex.ttl ("extension").

• Some props use the long naming convention (eg Equipment.Terminals), others a short convention (hasPart, connectedTo, connectedThroughPart)
• Svein proposed a different prefix cimr ("relations"), and different prop names.
• I'm sure we'll want to change the namespace, which currently is
  PREFIX cimex: <https://rawgit2.com/statnett/Talk2PowerSystem/main/demo1/cimex/>
• We may even want to register a permanent URL https://w3id.org/cimex that redirects to a resolvable location

[VladimirAlexiev]

This task is postponed for a later iteration. Assigning tentatively.

• similar title: Revise "cimex" namespace and derived prop names
• details: Svein wanted a different prefix cimr (CIM Relations)
• and more relations:
  hasA, partOf, memberOf, allocatedTo, connectedTo, electricallyConnectedTo, controlling, tripping
  • hasA: ownership or possession (eg ConductingEquipment has Terminal)
  • partOf: the part is integral to the whole (eg Bay in Substation)
  • memberOf: the part belongs to a group or set, but can exist independently (eg VoltageLevel in Substation)
  • allocatedTo: entity assigned to specific role, function, or market area (eg Generator allocatedTo BiddingZone)

[AndyKims]

I m confused about this task ( and quite many other similar tasks ). It is hard to know if this is R&D or simply fixing the Nordic44. If the latter, isn't it standardized how the model is described, i.e. if it is long or short convention? The reason I bring it up is that it will not be possible to know if the task should be prioritized into a sprint or not, because I dont understand if it brings us nearer a sprint goal / user story. Maybe we need to sit down in a workshop and put more details on this and other similar tasks so that we are not blocked when starting the sprint prioritzation.

[VladimirAlexiev]

• This is a Talk2PowerSystem task not Nordic44 task.
• The only Nordic44 task is check uniqueness of name #14 and I've asked @Sveino 2-3 times to move it
• This task was mostly requested by Svein, so it's up to him to decide in which sprint to put it (of course, approved by you and coordinated with other tasks)
• This task relates to "extend cimex with new inferred props" that may be needed for future questions
• The biz value is to have some "theory" or discipline about what derived props to define (something that Simen asked in CIM inference: derived (shortcut) props #16)

isn't it standardized how the model is described, i.e. if it is long or short convention?

The ontology (see link above) defines all props comprehensively, so the LLM can use them.
BTW @AndyKims, would you like a quick reading of it? Do you know Turtle? It's very simple and will give you some extra understanding of sem.tech.

We can keep prop names as is:

• long (eg cimex:Terminal.Equipment).
  Reason: it fits existing naming conventions, and parallels cim:Terminal.ConductingEquipment, cim:Terminal.AuxiliaryEquipment
• vs short (eg cimex:hasPart, connectedTo, connectedThroughPart).
  Reason: eg hasPart applies to both EquipmentContainer and Equipment so a prefix before . is not appropriate

But if the LLM is used to the fact that CIM props have a prefix, we might go for something like cimex:EquipmentOrContainer.hasPart

and quite many other similar tasks

Ping me with specific questions in such tasks.
But in general: don't worry about issues without a Milestone. Each such task will be discussed before it's put in a sprint

[Sveino]

I assume that we (me) need to write a spec, but what should be the scope?

#16 (comment) should give the outline of what I want.

[VladimirAlexiev]

@Sveino I updated #20 (comment) with the info from your
comment.

• I have a question: cim:VoltageLevel.Substation cims:multiplicity cims:M:1..1, so how can a VoltageLevel exist outside of, or in multiple Substations?

The way I see it we need these steps:

• Define the need (competency questions) for each derived prop
• Define the subprops (or other inference mechanisms) of each derived prop

[VladimirAlexiev]

• change cimex ontology URL #31 is done
• This task is postponed to S4.1 until we have valid use cases (competency questions) for each derived prop