A few little vocabulary page layout issues

[marcverhagen]

Because

The top-part of a vocabulary entry looks like

included in: 0.5.0 , 1.0.0
Thing > Annotation > Region > [Interval > Span
from 0.5.0 (last updated)

I have a strong suspicion that the last line is not needed because it follows from the first line (I am interpreting that line as "all the vocabulary versions that Span-v1 appears in"). And the meaning of "last updated" is not clear. The last time v1 was updated is never, because it was created only once. The last time Span was updated could be some other version of the type and vocabulary.

The "Also known as" list now lists the versions from our previous versioning scheme. Question: would this in the future also include v2 and v3 if we have them? It takes up a lot of real estate. The versions can be displayed more compactly, maybe something like:

versions: 0.4.0 0.4.1 0.4.2 v1
this version is included in: 0.5.0 , 1.0.0
Thing > Annotation > Region > [Interval > Span

Finally, it would be nice if the font size of "Span (v1)" in the header was a bit bigger.

Done when

No response

Additional context

No response

[keighrim]

I have a strong suspicion that the last line is not needed because it follows from the first line (I am interpreting that line as "all the vocabulary versions that Span-v1 appears in"). And the meaning of "last updated" is not clear.

I agree. I think we can remove the last line and change the first line. (IIRC, the last line was part of the "redirection" trick I initially added when migrating to the new type versioning (#197). The idea later dropped in 9e3fe89a36ff13a9f118e2c5b81bedabc24d9e93, but obviously not all of its code had gone then)

The "Also known as" list now lists the versions from our previous versioning scheme.

Also known as is actually a list of URIs that contains the same HTML contents. Thus, I don't agree we can reduce it into a list of version numbers. I originally named the field as identical to, but later changed. With the addition of similar to (#203 ), I think we should go back to the original name I used, if that indicates the meaning of those URIs more clear.

And then, if it takes up too much space at the top, we can consider move it (together with similar to) to the bottom-area of the page.

[marcverhagen]

Also known as is actually a list of URIs that contains the same HTML contents

Ah, I see, so if there had been a change from 0.4.0 to 0.4.1 then only 0.4.1 and 0.4.2 would have been listed. Then indeed a list of version numbers would not convey that some numbered versions are identical.

So conceptually we have really two lists of versions: (1) all the versions for the type, and (2) all the versions that are identical to the current version. I wonder if we could do something like the following (assuming for the sake of argument that there was a change from 0.4.0 to 0.4.1):

[0.4.1] [0.4.2 0.4.3 v1]

Basically two equivalence classes of types, with the current type in bold face.

Maybe the brackets are mostly obsolete for classes with one version (now adding future versions):

0.4.1 [0.4.2 0.4.3 v1] v2 v3

As far as I am concerned identical to and also known as are both fine.

[keighrim]

we have really two lists of versions: (1) all the versions for the type, and (2) all the versions that are identical to the current version.

Correct. However, the first numbers are not materialized anywhere on vocab webpages, while the second is listed as "a.k.a." lines.

If we go all the way back to 0.0.1 and construct the list of "all the versions for the type" as proposed, most types will have something like this .

• [0.0.1 0.0.2 0.0.3 ... 0.4.3 v1]

because most of the types were never actually changed throughout the history. The reason that the "a.k.a" lists only have 0.4.x versions is based on a pretty arbitrary decision I made (https://github.com/clamsproject/mmif/issues/14#issuecomment-1504439497). But I don't think any reference to 0.x vocab URIs is no longer relevant mostly because almost all the apps (actively developed) are using vX versions of vocab URIs.

That being said, note that from v2 (v3 for Annotation) there won't be "a.k.a" line at all simply because there won't be any "equivalence classes" that are not singleton.

Given all that, I don't think it's worth the effort to write code to build lists of the equivalence classes that are very much obsolete now.