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.

Sign up for GitHub

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

Jump to bottom

Simplifying place authority for SDP #51

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Simplifying place authority for SDP #51

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 45 additions & 14 deletions data-model/SDP-data-model-templates/place_sdp-template.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,19 @@
{
"id": "ARK/URI(?)",
"label": "",
"id": "URI",
Copy link
Collaborator Author

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",
Copy link
Collaborator Author

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.

"uniform_name": "",
"alt_name": [
Copy link
Collaborator Author

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.

"array of language-mapped strings"
],
"role": [
Copy link
Collaborator Author

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.)

{
"type": "CV of role types",
"associated_objects": [
"Array of Object ARKs. CMS will pull in the object's label/shelfmark and the place's attributed name information"
]
}
],
"description": [
"array of strings"
],
Expand All @@ -13,9 +23,26 @@
"uniform_name": ""
}
],
"associated_entities": [
"related_persons": [
Copy link
Collaborator Author

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)

{
"relation": "CV",
"id": "URI/ARK",
"note": [
"array of strings"
]
}
],
"related_places": [
Copy link
Collaborator Author

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)

{
"relation": "CV",
"id": "URI/ARK",
"note": [
"array of strings"
]
}
],
"related_works": [
Copy link
Collaborator Author

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.

{
"entity_type": "CV",
"relation": "CV",
"id": "URI/ARK",
"note": [
Expand All @@ -33,13 +60,6 @@
]
}
],
"location": [
Copy link
Collaborator Author

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

{
"type": "CV",
"coordinates": "",
"source": "URI?"
}
],
"note": [
"array of strings"
],
Expand Down Expand Up @@ -73,7 +93,18 @@
]
}
],
"contributor": [
"array of strings (CV)"
]
"meta": {
Copy link
Collaborator Author

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.

"contributor": [
"array of strings (CV); auto-populated based on the change_log?"
],
"last_updated": "xsd:dateTime",
"change_log": [
{
"date": "xsd:dateTime",
"contributor": "CV of Contributor Name (or URI?). Auto-populated based on user account (though needs to be editable to credit a contributing scholar rather than a data entry person)",
"change": "string describing what change was made?"
}
],
"created": "xsd:dateTime"
}
}