Status fields - Lisbon meetings

Alex

As result of the meetings in Lisbon, July 18‒21, 2024, during the DARIAH-EU Annual Event in Portugal, we take the resolution to change the «Status» field because the meaning and the values are not clear and consistent.

Little historic context of Status field:
The beginning of this field was to have control about the processes of Oral History (transcription, indexation and translation) done by different users at different time. In projects with different working profiles was necessary to mark the process status.

The first version had two different fields:

for the users, to mark the work was finished with the value: Finished
for admins to set if the word done is ok or need to be reviewed with values: Pending, Review, Validated.

When the movable heritage ontologies were created (mupreva, muvaet, qdp, etc) the Status field was «reused» adding two new values to control de records and objects: «Vacant» and «Deaccessioning» was introduced and the field meaning was blurred.

The proposal done in Lisbon by Swiss Team of SICF, @rca, @Margareth, @Jonas von Felten and Fanny this July was split the field into two different fields with clear meaning:

Data status
Object status

The current «Status» will change his values to adapt the new situation, mapping it in this way:

Status	Data status	Comment
Pending	Under study	Changing the name
	Achieved	New term
Review	To review	The term is more clear than current «Review»
Validated	Validated
Vacant	Vacant
	Unknown	New term
Deaccessioning		To move into the new «Object status» field «Depreciated»

Object status	Comment
Available
Accessible
Depreciated	get the data from «Deaccessioning» of the current «Status»
Destroyed
Lost
Unknown
Stolen

Basically I agree the proposal, it makes sense because the meaning that «Status» field is blurred and it has values that are not correct with the original meaning and «Object status» has a lot sense, it's necessary. But I want to introduce some changes to the proposal, because the original meaning of control the processes is necessary and maybe the change could had more sense in a global perspective.

My proposal is:

Add the finished control of Oral History to the records, it will accesible to be change by users to mark when they had finished his job in the record. Why a separated field?, because we need to assign permissions separately from other status fields, users need to change this field but only read (or not have access) the admin controls.
Questions as @Manuel Gozalbes has proposed. Will be necessary a list of processes to be controlled? as, translation, orthography, etc?
Remove the data control and object values «Vacant» and «Deaccessioning» and return to the original meaning of «Review by admins the work done by users», it could be named as «Revision state»
Add a «Data status» as Swiss team has proposed but focused it only in the data status, why? because I'm thinking that «Pending» is not the same that «Under study», «Pending» is something that somebody need to review and «Under study» is that the people working in the record has start to collect data, the record is in working progress.
Add «Object status» as Swiss team has proposed.
Add a field to add some remarks for the processes as @Manuel Gozalbes has proposed. It will be necessary to add comments for things that are not clear with the standard status fields, such as: To check the spelling of the «Description field».

Finished	Comment
Finished	a check box, that can be associated with specific processes as «translation», see «Process» in all media sections rsc12

Revision state	Comment
Pending	Need to be checked by somebody, initial state
To review	To check the record. The term is more clear than current «Review»
Validated	The revision was done and is ok

Data status	Comment
Under study	The documentation has start and is in working process
Achieved	The documentation process has finished
Unknown	Data not known
Vacant	the record ID can be reused, it will get the current data from «Vacant value» of the current «Status»

Object status	Comment
Available
Accessible
Depreciated	get the data from «Deaccessioning» of the current «Status»
Destroyed
Lost
Unknown
Stolen

Status remark	Comment
Status remark	free text field? or we need a list of processes and a free text?

I add a screenshot of the Process in media file to clarify the original meaning of «Status» and «Finished», take account that «Validation» field use the values of «Status»but only the original 3 values are filtered out:

What do you think?, some comments / changes?

Best

Manuel Gozalbes

Thank you, Alex. This upgrqde was really necessary. The new fields, Data status and Object status are perfect. To me, the values you have proposed should also work fine.
The only thing I'm not totally sure is how to deal with the 'finished' checkbox. I don' have clear if it will work as a general remark of the record. in a separate filed.
The 'status remark' should be a list for sure, because a free text field doesn't allow a full control for queries. Processes like translations, cataloguing or measuring can be marked in this way because are repetitive. Another question is that these processes are connected to the 'data status' field and, in fact, are a sort of annotation to its values. Is it feasible to create a dataframe in the 'data status' field to comment more precissely the marked values? Every comment concerning the 'data sataus' field should be absolutely connected to those values. I understand that dataframes are not totally tested, but it seems that are the perfect tool to gain control over this field and that can be perfectly adapted to the needs of the 'data status' field.

Jonas von Felten

Hi all, many thanks Alex, for the proposals. Your counter proposal is fine for us. A list of Status-annotations might get complicated in our case (e. g. "check mint", "show to Markus") so a free text comment would be sufficient. The idea of integrating a dataframe would be nice.
Additionally, do you plan to group these extended status fields in a section "Process" as in Images for example?

Alex

Jonas von Felten Additionally, do you plan to group these extended status fields in a section "Process" as in Images for example?

Yes of course!, it will be grouped into «Process». 😉

Manuel Gozalbes The dataframe seems to be good because is a powerful solution to cover any kind of requirement of any project.

Yes and we are going in these direction, but: his implementation will be step by step, dataframe concept is clear and powerful, but it needs to be tested in controlled spaces. As Karsten Tolled said in Frankfurt is a complex data model, Dédalo is ready into the «Type», «Mints» and other fields, but we want to be sure that the current solution is the way before implement the model in any components, in fact we the v5 data frame model still used and we can not removed because some installations has been not update and some questions are in the table as: how deal with «literal» data as dates, therefore, yes, Dédalo will go in those direction but please don't demand implement it in all fields... is not the time to it. 🙂

And in order of the «Status», two questions:

should be useful implement a portal with «Finished», «Revision state»?
and if yes:
should be useful implement inside the portal a date and people that done the job and the revisión?

The negative point of that is that you need to create the record to see the fields... but the positive thing is that you can add some specific task with some specific person assigned to this task and the portal could handle multiple things as Jonas plain: «Process images» it could be something as:

| id | task | users assigned | finished | admin assigned | revision status | date | status remark |

I don't see a portal for the «Data status» and «Object status» because they are global state of the data.

Best

Manuel Gozalbes

I think we are mixing two different things. Alex initially proposed two options for an extra field: list or free text. This means to create a new field. But the dataframe solution is something different, because adds information inside the data status field.
That is what I suggested, to create the dataframe which, in fact, includes both types of fields. So, if we choose the dataframe, we will have both options available inside the data status field by default, and we don't need and extra field.
The dataframe seems to be good because is a powerful solution to cover any kind of requirement of any project. I think is a huge step forward for Dédalo in general, but is a new development not implemented yet. Besides this, the data status field seems like a perfect scenario for testing the dataframe, because it will not record sensitive information. We deal with internal information that will never be published, so concentrating all the comments/requirements within the field seems a simple solution for the users (and a challenge for developers 🙂)