-
Notifications
You must be signed in to change notification settings - Fork 3
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
Simplifying place authority for SDP #51
base: master
Are you sure you want to change the base?
Conversation
@@ -1,9 +1,19 @@ | |||
{ | |||
"id": "ARK/URI(?)", | |||
"label": "", | |||
"id": "URI", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bringing in line with person and work
"type": "CV", | ||
"place_type": "CV", | ||
"uniform_name": "", | ||
"alt_name": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unlike person and work I don't think we'd need an ns_name field, but we would want the alt_name to have language mappings.
Alt names would be in general useful for places so we can have "Edessa" alongside "Urhay" "Urfa", etc. -- before even getting into the non-Latin-script versions of these names.
"alt_name": [ | ||
"array of language-mapped strings" | ||
], | ||
"role": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like 'role' necessarily for places. But some kind of mechanism similar to the role field in persons is needed so we can gather the attestations in SDP Objects. We would have name variants from these attestations, and we can also have role-like information ("place of copying", "previous repository", "current repository", "location of donation", etc.)
@@ -1,9 +1,19 @@ | |||
{ | |||
"id": "ARK/URI(?)", | |||
"label": "", | |||
"id": "URI", | |||
"type": "CV", | |||
"place_type": "CV", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI I'm still on the fence about this field. I'm thinking it would have keywords like "settlement", "mountain", "region", river", "building", etc. I think this could be a useful data point to include, but I'm not convinced it's something we want users to worry about inputting. And I also don't know if it distracts from the importance of these records as name authorities?
Connecting a place record to an external authority could give us some of this information without having to input it ourselves. Still, I could go either way.
] | ||
} | ||
], | ||
"related_places": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could include 'within' relations (e.g., settlement to region/district/country)
@@ -13,9 +23,26 @@ | |||
"uniform_name": "" | |||
} | |||
], | |||
"associated_entities": [ | |||
"related_persons": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most likely auto-populated based on associations made at the person level (e.g., when we select a person's birthplace)
] | ||
} | ||
], | ||
"related_works": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would include place of composition relationships (for the work, not a particular object). This may not be worth including. I added it only for the sake of being comprehensive with authority to authority relation options.
@@ -33,13 +60,6 @@ | |||
] | |||
} | |||
], | |||
"location": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted in the pr comment, I don't think it's worth including GPS coordinate locations. We could maybe have a mechanism to ingest this data from external authority files. But having a field for users to enter it distracts from the role of these place records as name authorities for SDP; we won't have geolocation data to add from the Sinai collection
"contributor": [ | ||
"array of strings (CV)" | ||
] | ||
"meta": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the draft of a 'meta' field also added to person and work records most recently.
@kirschbombe I made a few changes to places for us to discuss. Mostly these center on bringing places in line with our most recent changes to person and work templates. I also removed 'location', which is part of an effort to refocus these templates to solely be about repositories for data gathered from the Sinai collection (and I don't think that any manuscripts would have GPS coordinates in the colophon 😄 )
I'll make a few notes in the diff file.