Compare LinkML approaches

[VladimirAlexiev]

@bartkl @Sveino It would be nice to compare the LinkML approach in this repo to the one by SveinO, eg:

• https://github.com/Netbeheer-Nederland/im-cgmes/blob/main/schemas/core-equipment.yaml
• https://github.com/Sveino/Inst4CIM-KG/blob/develop/schemas/cim/func/linkml/core-equipment.linkml.yaml

Eg the former uses required, multivalued but the latter uses minimum_cardinality, maximum_cardinality.

[bartkl]

Yes, I noticed this difference as well.

Are these LinkML schemas exported by CIM Tool by any chance? If so, then it might be my own influence on Todd for making this choice. However, since then I've noticed that not all generators support minimum_cardinality and maximum_cardinality, whereas required and multivalued are commonplace. I think my preference would be to default to using required and multivalued, and also add the more precise cardinality constraints if it's really useful, but to never have only minimum_cardinality and/or maximum_cardinality. What do you think?

Note

This touches on a deeper issue with LinkML btw: the implementation consistency is not very great. Different generators make different assumptions and it's not always clear how the schema is interpreted. They have begun improving this by implementing a central SchemaView which is an API on top of the schema for consistent interpretation, however not all generators use this yet.

[bartkl]

Oh and of course you are suggesting to compare more broadly, which I definitely welcome. Not all choices I've been made were super deliberate this first time around, so it would definitely be great to align with each other.

[admin-cimug]

@bartkl : I remember that you and I ran into issues in June/July when we were collaborating that led us to the current state of what is represented in core-equipment.linkml.yaml. Trying to recollect details but I know this was the case.

cc: @VladimirAlexiev

[VladimirAlexiev]

@bartkl

• what does the linkml spec say about cardinalities? If certain backends don't support the spec, we should file bugs
• min, max is more precise, although the majority of props use 0,1 and infinity (I.e. same as required, multivalued)

[bartkl]

what does the linkml spec say about cardinalities? If certain backends don't support the spec, we should file bugs

This is the proper route, and we should do this. However:

• To my knowledge, the spec is an after-the-fact project and I don't think it's normative (and if it is, it might mean very little in practice). This is not a W3C body sadly ;).
• Given how many issues LinkML has and how relatively small the core team is, it might take a very long time before everything is smoothened out. They are working hard on it, but still.

This is why I think we need to make some choices with regards to conventions and perhaps even write some of our own generators (which we could contribute back) to gain time where it's needed. For the shorter term.

min, max is more precise, although the majority of props use 0,1 and infinity (I.e. same as required, multivalued)

I agree they are more precise, but I get the impression they are very little used and therefore don't have great support. Then again, I haven't tested this very thoroughly.

Moreover: there is something to be said for meeting users where they're at regarding familiarity and expertise. required and multivalued are immediately clear for devs, whereas cardinalities might trip some people up. Of course here I'm making the assumption it's devs who will be working with the LinkML schemas predominantly, which all depends on the org and culture. Thinking out loud here.

[tviegut]

what does the linkml spec say about cardinalities? If certain backends don't support the spec, we should file bugs

This is the proper route, and we should do this. However:

* To my knowledge, the spec is an after-the-fact project and I don't think it's normative (and if it is, it might mean very little in practice). This is not a W3C body sadly ;).

* Given how many issues LinkML has and how relatively small the core team is, it might take a very long time before everything is smoothened out. They are working hard on it, but still.

This is why I think we need to make some choices with regards to conventions and perhaps even write some of our own generators (which we could contribute back) to gain time where it's needed. For the shorter term.

min, max is more precise, although the majority of props use 0,1 and infinity (I.e. same as required, multivalued)

I agree they are more precise, but I get the impression they are very little used and therefore don't have great support. Then again, I haven't tested this very thoroughly.

Moreover: there is something to be said for meeting users where they're at regarding familiarity and expertise. required and multivalued are immediately clear for devs, whereas cardinalities might trip some people up. Of course here I'm making the assumption it's devs who will be working with the LinkML schemas predominantly, which all depends on the org and culture. Thinking out loud here.

@bartkl : Good reminder/referesher, This was why we landed where we did. I had tried to utilize min and max but there were scenarios that did not build downstream correctly so we had to land on a combination as you pointed out.

[VladimirAlexiev]

Sveino/Inst4CIM-KG#30

PREFIX cims: <http://iec.ch/TC57/1999/rdf-schema-extensions-19990926#>
select ?mult (count(*) as ?c) {
  ?x cims:multiplicity ?mult
} group by ?mult order by ?mult

There are 8 props that don't fit the required, multivalued scheme:

mult	c	note
cims:M:0..1	1123	optional singlevalued
cims:M:0..2	2
cims:M:0..n	462	optional multivalued
cims:M:1	304	required singlevalued
cims:M:1..1	3240	required singlevalued
cims:M:1..2	1
cims:M:1..n	100	required multivalued
cims:M:2..2	2
cims:M:2..n	3