Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

marking of a rudimentary description ("stub") #2700

Open
DenisNosnitsin1970 opened this issue Nov 28, 2024 · 12 comments
Open

marking of a rudimentary description ("stub") #2700

DenisNosnitsin1970 opened this issue Nov 28, 2024 · 12 comments
Assignees
Labels
app issues with functionality in the application guidelines issue with the data which has a relation to the guidelines and will lead to a change in the GL

Comments

@DenisNosnitsin1970
Copy link
Contributor

DenisNosnitsin1970 commented Nov 28, 2024

One question (possibly I overlooked this): is it possible to mark a rudimentary description as such (if the cataloguer wants others consider it as "stub")?
All description have the same indication "work in progress", but "stub" is more than that.

@eu-genia
Copy link
Contributor

eu-genia commented Nov 28, 2024

at the moment if you have no change element (or the only change element has who="PL" then "Stub" is printed
image

   {if (count($document//t:change[not(@who eq 'PL')]) eq 1) then
   <span class="w3-tag w3-red">Stub</span>
   else if ($document//t:change[contains(.,'completed')]) then
   <span class="w3-tag w3-gray" >Under Review</span>
     else if ($document//t:change[contains(.,'reviewed')]) then
   <span class="w3-tag w3-white" >Version of {max($document//t:change/xs:date(@when))}</span>
   else
<span class="w3-tag w3-red" >{"Work in Progress"}</span>

we can agree on when "Stub" must be printed

@eu-genia eu-genia added guidelines issue with the data which has a relation to the guidelines and will lead to a change in the GL app issues with functionality in the application labels Nov 28, 2024
@eu-genia
Copy link
Contributor

eu-genia commented Nov 29, 2024

@nafisa-valieva @CarstenHoffmannMarburg @karljonaskarlsson @thea-m @abausi
I think this is another small but important addition to the guidelines that we should all agree upon and implement: how we mark stub records and whether and how we want them visualized.

First I thought that the easiest would be that in all cases where only 1 change element is present AND this element contains the word "stub" we see the word "Stub" (as in the screenshot above). Then, as soon as there is a second change element, or there is just one change element but it does not contain the term stub this term would not show.

This sounds OK but we can also have stubs where changes occurred (like facs added, or something else) making a second change element necessary but the record is still a stub.

We could possibly say that as long as there is the word stub anywhere in the change history then "Stub" is printed, and when we think the record has stopped being a stub as it has been developed further then in the first change line the word stub must replaced with something like initial version or anything else. It is a bit awkward to have to modify earlier change elements but at the moment this is something that I can see as the easiest to implement. Other ideas?

@nafisa-valieva
Copy link

@nafisa-valieva @CarstenHoffmannMarburg @karljonaskarlsson @thea-m @abausi I think this is another small but important addition to the guidelines that we should all agree upon and implement: how we mark stub records and whether and how we want them visualized.

First I thought that the easiest would be that in all cases where only 1 change element is present AND this element contains the word "stub" we see the word "Stub" (as in the screenshot above). Then, as soon as there is a second change element, or there is just one change element but it does not contain the term stub this term would not show.

This sounds OK but we can also have stubs where changes occurred (like facs added, or something else) making a second change element necessary but the record is still a stub.

We could possibly say that as long as there is the word stub anywhere in the change history then "Stub" is printed, and when we think the record has stopped being a stub as it has been developed further then in the first change line the word stub must replaced with something like initial version or anything else. It is a bit awkward to have to modify earlier change elements but at the moment this is something that I can see as the easiest to implement. Other ideas?

This looks good for me! I am only afraid that we will never delete the word "stub" at the end :-)

@eu-genia
Copy link
Contributor

eu-genia commented Nov 29, 2024

Yes I am also afraid but since I always ask you to check how the record you have created/merged appears online would one not notice that the red "Stub" is there when it should not be?
I am really not sure that that is the best way, revising historical change is not the best practice, I am just trying to think of a way to somehow clearly distinguish stubs at first glance, without looking into the XML.

@DenisNosnitsin1970
Copy link
Contributor Author

This sounds best for me: "We could possibly say that as long as there is the word stub anywhere in the change history then "Stub" is printed, and when we think the record has stopped being a stub as it has been developed further then in the first change line the word stub must replaced with something like initial version or anything else". The cataloguer has to remove the stub-marking as soon as he/she does not consider the description a stub any longer (if I understood it right). Yes, the stubs should be distinguishable at first, glance.

@eu-genia
Copy link
Contributor

eu-genia commented Nov 30, 2024

In this case we would gave to check first all existing records that use stub in change and replace it when needed
https://betamasaheft.eu/xpath.html?xpath=%24config%3Acollection-root%2F%2Ft%3ArevisionDesc%2Ft%3Achange%5Bcontains%28.%2C%27tub%27%29%5D

@CarstenHoffmannMarburg
Copy link

I agree with Eugenia initial suggestion. It should be a solution, that is easy to handle and does not require awareness or action on the side of cataloguers, who will surely change in the future as well. I think, it is not a problem, if some rudimentary descriptions remain, that are not marked as "stubs" explicitely.

@karljonaskarlsson
Copy link

Eugenia's suggestion makes sense to me as well!

@thea-m
Copy link
Contributor

thea-m commented Dec 11, 2024

Do the guidelines also need to be updated regarding this? https://betamasaheft.eu/Guidelines/?id=revisions

@eu-genia
Copy link
Contributor

Yes, thank you!

@nafisa-valieva
Copy link

Do the guidelines also need to be updated regarding this? https://betamasaheft.eu/Guidelines/?id=revisions

Probably it makes sense to work on both updates together. If you do not mind, I will take care of it and then ask for your revision.

@thea-m
Copy link
Contributor

thea-m commented Dec 11, 2024

Thank you @nafisa-valieva that's great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app issues with functionality in the application guidelines issue with the data which has a relation to the guidelines and will lead to a change in the GL
Projects
None yet
Development

No branches or pull requests

6 participants