-
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
Further object revisions wlpotter #59
base: object-templates-revisions_wlpotter
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,6 +15,9 @@ | |
], | ||
"features": [ | ||
"array of CV" | ||
], | ||
"range": [ | ||
"array of strings" | ||
] | ||
} | ||
], | ||
|
@@ -32,7 +35,10 @@ | |
"writing_system": "CV", | ||
"script": "CV", | ||
"ink_color": "CV", | ||
"note": [ | ||
"script_note": [ | ||
"array of strings" | ||
], | ||
"hand_note": [ | ||
"array of strings" | ||
], | ||
"features": [ | ||
|
@@ -48,8 +54,8 @@ | |
], | ||
"page_layout": [ | ||
{ | ||
"columns": "int", | ||
"number_of_lines": "int", | ||
"columns": "", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": [ | ||
|
@@ -77,52 +83,76 @@ | |
{ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
|
||
"id": "URI", | ||
"type": "CV", | ||
"note": [ | ||
"array of strings" | ||
], | ||
"associated_dates": [ | ||
"associated_date": [ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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., |
||
"type": "CV", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" | ||
] | ||
|
@@ -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": [ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": [ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": [ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": "", | ||
|
@@ -219,11 +356,13 @@ | |
] | ||
} | ||
], | ||
"other_versions": [ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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": [ | ||
|
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.
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.