Immovable cultural property

Alex

@rca @Manuel Gozalbes @elena @Ruth @Markus @Mariajobrador

Dear all

In the way that we are working to unify the different movible sections to new TCH (tangible cultural heritage) we are planing to create immovable section with a TCHI (tangible cultural heritage immovable) to unify different sections as "Finds", "Archaeological sites", "Places", etc...

The plan is to create a common section with all functionalities of other sections that means the same thing, a Immovable cultural property and his own things (including UE, places, sites, finds, etc...) in a hierarchical tree as "Finds" does (numisdata279), and replace current sections moving his data to the new section.

We want to ask you if you have some comments or ideas or... to implement or to change the plan.

Thanks and we are waiting your feedback... 🙂

Best

elena

Hi everybody
This is what we have being working to from years, am I right? So you have my support and a doc with my ideas, do you need something else?
Best!
Elena

Alex

Hi!

Immovable heritage section is ready to be implemented. The next step is move the current numisdata279 Finds to this new section Immovable.

The mapping to move Finds to new Immovable heritage will be:

numisdata	tchi	old name	new name	comment
numisdata279	tchi1	Finds	Immovable
numisdata500	tchi8	Publishable	Publishable
numisdata211	tchi15	Name	Name
numisdata260	tchi18	Indexation	Indexation
numisdata294	tchi12	Status	Status
numisdata571	tchi11	Usable in indexing	Usable in indexing
numisdata1192	tchi13	Previous code	Code
numisdata1193		Other code		it could be enter into other codes portal but, this field is not used in current installations
numisdata1100	tchi17	Identifying image	Identifying image
numisdata1102	tchi31	Images	Images
numisdata219	tchi60	Size	Total objects
numisdata1254	tchi61	Size description	Object list description
numisdata214	tchi20	Time frame	Dating
numisdata262	tchi24	Private information	Notes
numisdata140	tchi22	Public information	Public information
numisdata220	tchi29	Bibliography	Bibliography
numisdata215	tchi32	URL	URI
numisdata997	tchi14	Other codes	Other codes
numisdata293	tchi21	Place	Location
numisdata212	tchi26	Geolocation	Space frame
numisdata1259	tchi27	Coordinates	Coordinates
numisdata213	tchi25	Map	Geolocation
numisdata321	numisdata250	coins	Numismatic Objects	is not necessary transform this field, is calculated with the relations
numisdata567	tchi39	Father	Dependent of
numisdata566	tchi40	Children	Children
numisdata1196	tchi35	Authorship	Authorship

Previously to move data I have a question about Size and Size description.
This current two fields has not a place into the new tchi and the question is:
How should these fields be added in a common way, thinking about archaeological sites? (not only for Numismatics Finds)

And the implementation is ready so, the main idea is implement the update inside the v6.2 that will be ready very very soon (will be published next week), if you have some comments, speak now or forever hold your peace!!!!

Best

Manuel Gozalbes

Moneda iberica is not using 'Size' and 'Size description'. These fields were originally planned to store info from hoards (numisdata 279 was for finds and hoards). Now the model is different because we have numisdata5 for hoards/sets, where composition (numisdata1474) and biography (numisdata1466) constitute a more complete solution for describing sizes.

Alex

So, are you saying that, if someone has information in Size and Size description, the update will delete it?
In my opinion we need to find any place to move this data, delete data should not to be an option. Maybe this way could be OK for Moneda Ibérica project but it's not alone, other projects are using numisdata ontology.

Best

PaCo

If Manuel's comments are correct, I think they should be moved to deprecated fields temporarily to allow users who are using these fields now to make the transition when they can or want to.

elena

Hello!
We are using this fields but I always thought that they should be calculated by the relations to the coins found in that place that they are already related to.
The description of the size is funny too, as we are duplicating the information… and is not a “recuperable” information because is not related to the list of mints nor the list of types. Same happens with the old and new model of hoards or sets.
But sometimes maybe someone dont have (or dont want) all the coins in the system, so in that case is useful. Same with the hoards, and these fields are still there.
I still think there is a duplicity or a fine not so differenced line between hoards and places. Still, there is a field in the hoards model for “place” and I wander what should I put there because it could duplicate the data.
Maybe, as the circumstances are so variable, you should mantain the field and rename it as: objects related and total of objects.
And we should rethink about places/inmobile and tresures/hoards…

Alex

Hi elena

elena you should mantain the field and rename it as: objects related and total of objects.

Ok, I will create two new fields in tchi to move the current data:

objects related
total of objects

And another questions here:

Immovables section (tchi1) has biography (tchi54) field, the same portal that hoard/set, but it doesn't' has composition fields, it will be necessary?

If yes and as Manuel said, it could be better if @elena can will move this data into this fields? and when it will finished delete the objects related and total of object fields. So, these two fields are ‘only for moving current data’?

Best

Manuel Gozalbes

As Elena said the main problem is that

elena We are using this fields but I always thought that they should be calculated by the relations to the coins found in that place that they are already related to.

Further developments in the sense of recording quantities manually in the tchi1 section are dangerous because of that. A different thing is to record quantities in hoards / sets, as I said before, because in that case the contents may change after different authors or sources, and its interesting to present the different descriptions in a structured way.
The same model may be useful for tchi1 if the purpose of that information is only to summarise the finds, like in the the example of the last post of Elena. But we must bear in mind that the only purpose of these fields is to present finds in brief.
It's also helpful when the information is vague and/or are not recorded into the 'numismatic object' section.

elena

Hi!
I think the difference between object related and composition fields is that the first is a list and the other one is meant to be a narration. So I feel that they can live together and the decission of using it or not is in the researcher.
What do you think?

Best

Alex

elena the difference between object related and composition fields is that the first is a list and the other one is meant to be a narration.

Could you please give an example of that?

Because composition (numisdata1474) has 6 fields:

Composition remark numisdata1475
Discovery method numisdata1476
Discovery method remark numisdata1477
Composition by period numisdata1478
Composition by Era numisdata1479
Data correction by period numisdata1493

My questions are:

Composition needs to be implemented in immobile section tchi1?
All these fields?
Only xxxx?

Best

elena

Of course, as example with the data of wondercoins:
Total of objects (Tamaño):
"38"
Objects related (Descripción Tamaño):
"32 denarios republicanos
6 denarios de Augusto"
Composition remark (Notas sobre la composición):
"Destaca el acuñado denario en Hispania por Cneo Pompeyo el Joven (RRC 469/1a) y algunos denarios de las legiones de Marco Antonio (RRC 544/19, 544/24 y 544/25). La ocultación cierra con denarios de Augusto, más concretamente con los del reverso toro embistiendo (RIC I2 165 y 167)."

I think it would be useful to have all the composition fields in tch1, as they are very useful.

Best!

Alex

elena Objects related (Descripción Tamaño):

I think that the name is confusing, because it's a text field, and these information is not a 'real' relation with the objects.

I proposal:

Object list description

Or something like that.

Objects related seem to mean as a links to objects in different sections, as coins (numismatic objects) or any other tangible heritage in tch1.

Best

elena

Alex I agree, "object list" or better "List of objects" could be better...

elena

Manuel Gozalbes I agree too, sumarizing the finds are useful too, so using the same model has sense.

Manuel Gozalbes

Is it possible to add a field for documents in the tchisection?

Alex

Manuel Gozalbes Is it possible to add a field for documents in the tchisection?

Yes! of course. It was done into the ontology:

Dédalo 2024-08-09T19:10:38+02:00 Benimamet

Update your installation to get it.

Best

Manuel Gozalbes

Thank you. 🙂