Object templates revisions wlpotter #52
Conversation
wlpotter
added
sdp
| "form": "CV", | ||
| "binding": { | ||
| "has_binding": "boolean", | ||
| "note": [ | ||
| "array of strings" | ||
| ], | ||
| "features": [ |
There was a problem hiding this comment.
I don't think binding features is something we'll implement any time soon?
| @@ -40,7 +37,7 @@ | |||
| }, | |||
| "events": [ | |||
| { | |||
| "id": "ARK", | |||
| "id": "URI", | |||
There was a problem hiding this comment.
Events would at most have a uniquely-generated id. and maybe not even that.
In any case, events might be for a later phase entirely. I could imagine that for now we just have paratexts we record as part of the codicological or textual objects. These might have evidence for events, but maybe for now they remain wrapped up in the paratexts. Down the line we can mine these paratexts for event information.
| ] | ||
| } | ||
| ], | ||
| "paratexts": [ |
There was a problem hiding this comment.
A paratext could have as its scope the manuscript object (e.g., waqf or custody notes?). However, I wonder if for now we should keep these as fields in the codicological (for colophons, etc.) or textual (for rubrics, and perhaps even readers notes?) level.
If we do ever spin them out into their own textual artifact-like object records this point might be moot.
| ] | ||
| } | ||
| ], | ||
| "associated_entities": { |
There was a problem hiding this comment.
I made this a bit more like the related objects field where we have a containing field 'associated_entities' along with more specific fields for each type. I don't think this list is exhaustive necessarily. For example, we could 'attested' as well as 'associated' persons and places. I'm also on the fence about making something like 'attributed_author' be a top-level category at the textual artifact level.
| "layer": "int" | ||
| } | ||
| ] | ||
| "related_objects": { |
There was a problem hiding this comment.
This is based on what we discussed last week where we have a predetermined set of 'top-level' relationship types ('has_part', etc.) each with their own list of available fields, including a mechanism for further specifying the nature of the relationship with type.
| } | ||
| ] | ||
| "related_objects": { | ||
| "has_content": [ |
There was a problem hiding this comment.
is 'has_content' too broad? Would/could illustrations eventually get their own records? Coming from the other direction, if we don't give paratexts their own records, we really are only interested in describing with this relationship the major contents of the ms
| @@ -6,7 +6,7 @@ | |||
| "array of strings" | |||
| ], | |||
| "extent": "", | |||
| "work": "URI", | |||
| "embodies": "URI of Work Authority File", | |||
There was a problem hiding this comment.
Trying this out. In keeping with the way we've done other relationships, I've changed the field name to be the 'property'/'predicate'. For reference, this term is used in the Linked Ancient World Ontology to connect "Written Works" to "Conceptual Works" (i.e., a written work embodies a conceptual work).
| "note": [ | ||
| "array of strings" | ||
| ] | ||
| "attested_entities": { |
There was a problem hiding this comment.
see under codicological unit
| } | ||
| ], | ||
| "associated_entities": { |
There was a problem hiding this comment.
see under manuscript objects.
| } | ||
| ] | ||
| "related_objects": { | ||
| "contained_in": [ |
There was a problem hiding this comment.
I didn't like 'content_of' as the reciprocal but am having trouble coming up with good language here.
| ] | ||
| } | ||
| ] | ||
| }, | ||
| "associated_dates": [ |
There was a problem hiding this comment.
I wonder if for now we need to decide between 'event' and 'associated_date'? Based on our current data and what our phase 1 scope is, I think 'associated_date' is the better field. We could add additional fields to it for something like date_ns (transcribing the date from the ms), some indication of the dating system used by the date as found in the manuscript, etc. For now we could include source info (such as, 'Found in scribal colophon') in the note field.
Rather than using the type field, we could structure this field like the related objects:
{
...
"associated_dates":
{
"creation": [array of objects further specifying, if needed, a date],
"acquisition": [object describing the acquisition.]
}
}
I think using a dates field will be easier for initial data gathering, as its focus is on the information on the page (the date transcribed from the ms). However, it would be difficult to start associating together people, places, and dates all occurring in the same paratext that is describing/providing evidence for an event.
| @@ -35,8 +35,11 @@ | |||
| "note": [ | |||
There was a problem hiding this comment.
For some reason I can't add a comment above here...But I just noticed that support (line 10-20) is missing a 'range' field, which would function like the one in writing_and_hands to specify which folios are a given support type. This field could be optional, a null value meaning that the entirety of the unit is the specified support type. But if there are multiple in the same unit, I think we'd want some kind of indication of which folios are which.
@kirschbombe here are a few revisions to the object templates, mostly as a jumping off point for our current review cycle.
I'll try to add a few comments today or tomorrow; feel free to make any notes, of course.