HED-SCORE library schema 1.0.0 release

[tpatpa]

Following an extensive revision process of the schema, we can officially release it.

[IanCa]

I was working on the tools and fixed a bug finding the following issue:

The term "Body-part" is already used in the standard schema.
Item/Biological-item/Anatomical-item/Body-part
Finding-property/Location-property/Body-part

I didn't find any other new duplicates, but I will update you immediately if I do...

[tpatpa]

Thanks!
Body-part in HED-SCORE is used to characterize semiologic findings and, indeed, partially overlaps with Item/Biological-item/Anatomical-item/Body-part.

/Finding-property/Location-property/Body-part:

• Body-part-eyelid
• Body-part-face -> /Item/Biological-item/Anatomical-item/Body-part/Head/Face
• Body-part-arm -> /Item/Biological-item/Anatomical-item/Body-part/Upper-extremity
• Body-part-leg -> /Item/Biological-item/Anatomical-item/Body-part/Lower-extremity
• Body-part-trunk -> /Item/Biological-item/Anatomical-item/Body-part/Torso
• Body-part-visceral
• Body-part-hemi

With this proposal, specifically, the use of relatedTag and suggestedTag attributes with standard tags, we can partially resolve this by adding suggestedTag to /Finding-property/Location-property pointing to the standard tags in Item/Biological-item/Anatomical-item/Body-part.

Any thoughts on whether there is room for the rest of the SCORE tags (eyelid, visceral, hemi) in the standard schema?

@VisLab @dorahermes @dungscout96 @IanCa @happy5214

[VisLab]

We're going to work through how the merged schema would work with and without the merge using this proposed score. The current thought from the HED working group (after a very vigorous discussion) is now that we would allow subtrees of a library schema to hook on to anywhere in the standard schema. I'd like to work through this with this new score in the next few days before release and see how it would like. I may merge into the prerelease after I have a chance to look at it, but I would like to keep open the option of using a version merged with the standard schema for the final release as it would greatly improve the usability and we could really leverage the relatedTag and suggestedTag. Give us a chance to work through the details and then maybe we can have a meeting to go over it. Great news that the license issues have all been resolved!

…

On Thu, Jan 19, 2023 at 5:51 PM Tal Pal Attia ***@***.***> wrote: Thanks! Body-part in HED-SCORE is used to characterize semiologic findings and, indeed, partially overlaps with Item/Biological-item/Anatomical-item/Body-part. /Finding-property/Location-property/Body-part: - Body-part-eyelid - Body-part-face -> /Item/Biological-item/Anatomical-item/Body-part/Head/Face - Body-part-arm -> /Item/Biological-item/Anatomical-item/Body-part/Upper-extremity - Body-part-leg -> /Item/Biological-item/Anatomical-item/Body-part/Lower-extremity - Body-part-trunk -> /Item/Biological-item/Anatomical-item/Body-part/Torso - Body-part-visceral - Body-part-hemi With this proposal <#52 (comment)>, specifically, the use of relatedTag and suggestedTag attributes with standard tags, we can partially resolve this by adding suggestedTag to /Finding-property/Location-property pointing to the standard tags in Item/Biological-item/Anatomical-item/Body-part. Any thoughts on whether there is room for the rest of the SCORE tags (eyelid, visceral, hemi) in the standard schema? @VisLab <https://github.com/VisLab> @dorahermes <https://github.com/dorahermes> @dungscout96 <https://github.com/dungscout96> @IanCa <https://github.com/IanCa> @happy5214 <https://github.com/happy5214> — Reply to this email directly, view it on GitHub <#54 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJCJOSDI5VDRPI6BUNJ7ALWTHHO5ANCNFSM6AAAAAAUAZCWSU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tpatpa]

Great, thank you @VisLab ! Looking forward to discussing this further.
Once this version is merged and used by the HED tools, we can fully validate the HED-SCORE bids-example ! 🥳

[dorahermes]

It is difficult for me to compare the old and new version, because the name of the document has changed with the new version.

• The changes to body-part all look good!
• It seems like 1.0.0 includes the new body part section, but the old prologue?

[dorahermes]

The prologue still seems to be an old prologue, rather than the new one with the references?

[tpatpa]

There is more information in the epilogue!
Then both are shown in the browser viewer's 'Schema information' section.

[dorahermes]

Ok, thanks!

[VisLab]

@tpatpa I noticed that score_0.0.1 is removed. Since we didn't officially tag it as a release, I guess that is okay, but I wanted to verify. We're going to have to develop a policy about how this is handled.

I have created a score branch. Would you please change your PR to merge into the score branch.
We need to rerun the latest schema validators and do a final check before creating an official release.
It will be easier to do that on a separate branch. Thanks!

[tpatpa]

Yes, score_0.0.1 was removed on purpose. I feel it is too preliminary... But, I can, of course, restore if needed.

[VisLab]

@tpatpa @dorahermes @dungscout96 one other question.... This is about how we should handle prereleases.

We have links to both current and prerelease versions in the README and other places. Eventually @dungscout96 is going to change the schema browser so that all of these are available from one browser. However, until this happens if we completely remove the prerelease these links will break. Even after there is a merged viewer, it would be good to have an anchor point to a prerelease.

When we do the actual release with tags etc. we could create a copy of 1.0.0 as 1.0.1 prelease so that there will be an anchor point going forward. If there are other ideas on this let me know.

[dorahermes]

lgtm!