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

Further object revisions wlpotter #59

Open
wants to merge 2 commits into
base: object-templates-revisions_wlpotter
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
229 changes: 184 additions & 45 deletions data-model/SDP-data-model-templates/codicological-unit_sdp-template.json
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,9 @@
],
"features": [
"array of CV"
],
"range": [
"array of strings"
]
}
],
Expand All @@ -32,7 +35,10 @@
"writing_system": "CV",
"script": "CV",
"ink_color": "CV",
"note": [
"script_note": [
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In airtable we distinguish script and hand notes. It may be worth having the two fields: the script note for comments about how the script is used; the hand about specific characteristics of this particular instantiation of the 'ideal' script type.

"array of strings"
],
"hand_note": [
"array of strings"
],
"features": [
Expand All @@ -48,8 +54,8 @@
],
"page_layout": [
{
"columns": "int",
"number_of_lines": "int",
"columns": "",
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've removed the value constraint for 'columns' and 'number_of_lines' so we can capture cases where there's a range (e.g., "16-20")

"number_of_lines": "",
"column_width": "",
"margin_width": "",
"note": [
Expand Down Expand Up @@ -77,52 +83,76 @@
{
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Events deserve their own discussion. I think we'll need to weigh their usefulness and expressiveness as research data points against how difficult it might be to implement for users inputting data about manuscripts.

One option for restructuring this field, which would make it more like 'paratexts' or 'related_objects' would be to have top-level event types:

{
  "events":
    {
      "production": [array of event objects],
      "ownership": [array of event objects],
      "use": [array of event objects],
      "custodianship": [array of event objects]
    }
}

"id": "URI",
"type": "CV",
"note": [
"array of strings"
],
"associated_dates": [
"associated_date": [
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all in the context of an "events" field, FYI. I think I mostly just reordered the sub-fields.

{
"date_type": "CV",
"date_human_readable": "",
"date_normalized": "ISO-8601 Dates",
"note": [
"array of strings"
]
}
],
"associated_entities": [
"associated_person": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
],
"associated_place": [
{
"entity_type": "CV",
"role": "CV",
"id": "URI/ARK",
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
],
"note": [
"array of strings"
],
"sources": [
"ARK/ID of a Paratext? URI of a Zotero Bibl?"
"Paratext ARKs | Zotero URI(?)"
]
}
],
"paratexts": [
{
"id": "ARK",
"type": "CV",
"locus": "",
"transcription": {
"$langCode": "Note: lang code refers to the language of transcribed text. transcription object may have multiple $langCode fields."
},
"translation": {
"$langCode": "Note: lang code refers to the language of translated text. translation object may have multiple $langCode fields."
},
"note": [
""
],
"attested_entities": {
"paratexts": {
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've updated paratexts here in keeping with how we are structuring 'object_relationships' so that there are named top-level paratexts types. We can decide separately what these top-level types might be, but I think that 'colophon' and 'inscriptions' are sufficiently generic to start with.

"colophon": [
{
"id": "ARK",
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 wonder if we can use ARK sub-namespaces for paratexts? e.g., ark:/21198/z1gm9bpz/parat1? The db might be able to auto-generate the sub-namespace id to keep it unique and opaque

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

This field would let us further specify paratexts types. More useful for inscriptions, but even for colophons we could distinguish "scribal colophon" vs a colophon copied from an exemplar (which sometimes happens in Arabic mss, and in Syriac too I think)

"locus": [
"array of strings"
],
"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
{
"en": "note: field name is an ISO langcode"
}
],
"attested_person": [
{
"relation": "CV",
"id": "URI",
"attested_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.

I realized we would probably want to grab the attested names from colophons, etc. (we are having RAs grab these into airtable currently)

"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
{
"en": "note: field name is an ISO langcode"
}
]
},
"note": [
"array of strings"
]
Expand All @@ -132,35 +162,142 @@
{
"relation": "CV",
"id": "URI",
"attested_name": {
"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
{
"en": "note: field name is an ISO langcode"
}
]
},
"note": [
"array of strings"
]
}
]
}
}
],
"associated_entities": {
"associated_person": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
],
"attested_date": [
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 also added an "attested_date" field for dates coming from paratexts. Dates are a whole conversation topic itself, but I think we will want to have the option to record more info about attested dates than those estimated through paleography. Here I've including 'dating_method' (e.g., Seleucid, Anno Mundi, Hijri, etc.) as well as fields to transcribe and translate the date.

{
"type": "CV",
"dating_method": "CV",
"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
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 different from the human readable in that it doesn't convert the date into Gregorian.

{
"en": "note: field name is an ISO langcode"
}
],
"date_human_readable": "Conversion of the date into a Gregorian calendar system, but still a human readable label",
"date_normalized": "ISO 8601 date/date range"
}
]
}
],
"associated_place": [
"inscription": [
{
"relation": "CV",
"id": "URI",
"note": [
"id": "ARK",
"type": "CV",
"locus": [
"array of strings"
],
"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
{
"en": "note: field name is an ISO langcode"
}
],
"attested_person": [
{
"relation": "CV",
"id": "URI",
"attested_name": {
"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
{
"en": "note: field name is an ISO langcode"
}
]
},
"note": [
"array of strings"
]
}
],
"attested_place": [
{
"relation": "CV",
"id": "URI",
"attested_name": {
"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
{
"en": "note: field name is an ISO langcode"
}
]
},
"note": [
"array of strings"
]
}
],
"attested_date": [
{
"type": "CV",
"dating_method": "CV",
"transcription": [
{
"syr": "note: field name is an ISO language code"
}
],
"translation": [
{
"en": "note: field name is an ISO langcode"
}
],
"date_human_readable": "Conversion of the date into a Gregorian calendar system, but still a human readable label",
"date_normalized": "ISO 8601 date/date range"
}
]
}
]
},
"associated_dates": [
"associated_person": [
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 reordered these. I'm really not sure if they will be used. When would we have persons or places that are not otherwise attested in the ms?

{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
],
"associated_place": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
],
"associated_date": [
{
"date_type": "CV",
"date_human_readable": "",
Expand Down Expand Up @@ -219,11 +356,13 @@
]
}
],
"other_versions": [
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 realized we were missing this field. While it would primarily be used in manuscript objects, I wonder if we would want to provide any URI/identifier that is assigned for the codicological unit by the linked mss aggregator?

"array of URIs"
],
"iiif": {
"iiif_manifest": "Manifest URL",
"text_direction": "CV",
"viewing_hint": "CV",
"range": "???"
"viewing_hint": "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.

I removed the 'range' field since I didn't know what it was for...

},
"related_objects": {
"has_content": [
Expand Down
Loading