Open HLWeil opened 5 months ago
Currently, the whole specification of how to handle
Comments
is a bit messy. In ISA, a lot of types have a property calledComments
of type ISA Comment array. Unfortunately, not all of their equivalent types in Schema.org contain a propertycomment
of range https://schema.org/Comment. So for some cases like https://schema.org/Person, we usedisambiguatingDescription
of rangeText
.
I agree, it is not nice at the moment. But I think there is no better way around this Problem.
But this is not ideal, as now the encoders for the same type in ISA needs to produce different objects in JsonLD.
This is just a technical problem, right? I don't think this is the right place to discuss it, but from my point of view, it's not a big hurdle. We just define two different encoders for the ISA type Comment
, so there should be no problem with them producing different json objects.
Additionally, currently the Investigation profile defines
disambiguatingDescription
, even though this is inconsistent with the otherCreativeWork
objects.
That is indeed a bug, as far as I can tell. Same holds for ScholarlyArticle
. @stuzart, do you know if this is by design or just a bug?
Currently, the whole specification of how to handle
Comments
is a bit messy. In ISA, a lot of types have a property calledComments
of type ISA Comment array. Unfortunately, not all of their equivalent types in Schema.org contain a propertycomment
of range https://schema.org/Comment. So for some cases like https://schema.org/Person, we usedisambiguatingDescription
of rangeText
. But this is not ideal, as now the encoders for the same type in ISA needs to produce different objects in JsonLD. Additionally, currently the Investigation profile definesdisambiguatingDescription
, even though this is inconsistent with the otherCreativeWork
objects.Not sure how to handle this. Just wanted to write it down before it gets forgotten.