Closed brandonnodnarb closed 3 years ago
Hi @brandonnodnarb see my comment on the Pyroxene
issue.
Hmmm... I had a look. Apologies, the first go round on issue #128 I was focused on the `deprecation' aspects.
Was the deprecation because the IRI slug doesn't match the class label? Aren't the IRIs arbitrary? Which is to say they can be treated as arbitrary now that they are not a proxy for the class label as well.
I can deprecate the classes and create new ones. I just want to make sure I understand the rationale...mostly so I don't munt anything...
Also applies to #213.
It's not about whether the identifier matches the class label, at least not directly.
The deprecation is called for if the local identifier (what you call the IRI slug, I think) is not spelled in the same way the actual concept is spelled in American English. (This is a reality of SWEET, but can be a bit of a red flag for semantic practitioners, because many will argue the identifier should not contain any semantic information. We will not re-argue that question here, because SWEET long ago decided to make all the the local identifiers out of the actual words—hence the idea that SWEET is a bit of a dictionary, more than a conceptual model.)
So in this case we have a SWEET identifier for a term that doesn't actually exist, and that's not good, and we need to fix it. Ideally by pointing anyone who uses that old identifier to the correct identifier.
So this modification doesn't look OK to me, because we're changing the label but not dealing with the problem of the identifier, which is fundamental. And properly dealing with the problem of the identifier requires not simply changing this identifier to the new spelling; we have to deprecate the original identifier; annotate that deprecated identifier to explain the reason and point to the new identifier; and add the new identifier with the correct information.
Thank you for your replies @graybeal. I can't say I agree; I don't currently believe non-opaque IRIs to be fundamental (to SWEET or otherwise) or that opaque IRIs are a problem --- or that SWEET need to have only one type for that matter.
However, the replies suggest continuing with non-opaque IRIs --- at least until such time that issue #49 is resolved. That's what I was asking for confirmation on.
Updated.
@graybeal can you please review ? Thanks
NOTE: did not change URI