Fix support for literal mappings.#624
Conversation
Since the LinkML-generated Mapping class does not, in itself, validates the post-conditions specified in the schema, it cannot validate that a Mapping object is created with either a subject_id or (if subject_type is `rdfs literal`) a subject_label (likewise for the object side). Instead, that validation is performed by custom code executed as part of the parsing code. However, the present validation is bogus because the check on the value of `subject_type` and `object_type` is trying to compare the value of the slot to a literal string, instead of a EntityTypeEnum object. We fix that comparison here.
| try: | ||
| m = Mapping(**mdict) | ||
| if m.subject_type == "rdfs literal": | ||
| if m.subject_type == EntityTypeEnum(EntityTypeEnum["rdfs literal"]): |
There was a problem hiding this comment.
Note: As strange as it may look like, this is the normal way of comparing LinkML-defined enum values.
A comparison like this:
m.subject_type == EntityTypeEnum["rdfs literal"]would not work because EntityTypeEnum["rdfs literal"] is not the actual enum value, it is the LinkML PermissibleValue object that represents the enum value (that’s not the same thing!). We must give that value to the EntityTypeEnum constructor to obtain an actual enum value that we can compare to the value of the slot.
See here for details, and here for a request for an easier way of working with LinkML enums.
(Of course in our case this is make even weirder by the fact that our enum values contain space characters, and LinkML does not allow to distinguish between the actual value to be used in data and the symbol used in Python code.)
matentzn
left a comment
matentzn
left a comment
There was a problem hiding this comment.
Much appreciated, thank you!
2 participants
Since the LinkML-generated
Mappingclass does not, in itself, validates the post-conditions specified in the schema, it cannot validate that a Mapping object is created with either asubject_idor (ifsubject_typeisrdfs literal) asubject_label(likewise for the object side).Instead, that validation is performed by custom code executed as part of the parser (after the parsing proper has been done, but before return a
MappingSetDataFrameto the caller).However, the present validation is bogus because the check on the value of
subject_typeandobject_typeis trying to compare the value of the slot to a literal string, instead of a EntityTypeEnum object. We fix that comparison here.