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

Object templates revisions wlpotter #52

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Object templates revisions wlpotter #52

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
eee76b2
Update manuscript object for discussion
wlpotter Oct 10, 2022
5fefce4
fix cardinality typo
wlpotter Oct 10, 2022
0c286c1
Update codicological template for discussion
wlpotter Oct 10, 2022
df03af5
Update textual artifact template for discussion
wlpotter Oct 10, 2022
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
111 changes: 75 additions & 36 deletions data-model/SDP-data-model-templates/codicological-unit_sdp-template.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,11 @@
"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.

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.

"array of strings"
],
"features": [
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe 'Rubrication' would be a feature we could put here?

"array of CVs"
],
"corresponding_textual_artifacts": [
"ARK"
"Array of Textual Artifacts ARKs"
],
"range": [
"array of strings"
Expand Down Expand Up @@ -72,7 +75,7 @@
},
"events": [
{
"id": "ARK",
"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.

see comments in manuscript object.

"type": "CV",
"note": [
"array of strings"
Expand All @@ -97,7 +100,7 @@
}
],
"sources": [
"ARK?"
"ARK/ID of a Paratext? URI of a Zotero Bibl?"
]
}
],
Expand All @@ -115,30 +118,48 @@
"note": [
""
],
"attested_entities": [
{
"entity_type": "CV",
"role": "CV",
"id": "URI/ARK",
"attested_name_NS": "",
"attested_name": "",
"note": [
"array of strings"
]
}
]
}
],
"associated_entities": [
{
"entity_type": "CV",
"relation": "CV",
"id": "URI/ARK",
"note": [
"array of strings"
]
"attested_entities": {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

see comments in manuscript object.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

oh wait, no this is a bit different. So in texts and codicological units I've kept 'paratext' as a field. Here I've included 'attested' rather than 'associated' entities, and I just updated the field to match with 'associated_entities' so that it has 'attested_person' and 'attested_place'.

"attested_person": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
],
"attested_place": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
]
}
}
],
"associated_entities": {
"associated_person": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
],
"associated_place": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
]
},
"associated_dates": [
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 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.

{
"date_type": "CV",
Expand Down Expand Up @@ -204,15 +225,33 @@
"viewing_hint": "CV",
"range": "???"
},
"contributor": [
"array of strings (CV)"
],
"related_objects": [
{
"relationship_type": "CV",
"object": "ARK",
"position": "int",
"layer": "int"
}
]
"related_objects": {
"has_content": [
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

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

{
"type": "CV",
"object": "ARK",
"position": "int"
}
],
"part_of": [
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

codicological units have both child text relationships ('has_content') and parent ms object relationship ('part_of').

For the 'part_of' I'm thinking it would be auto-populated and so not necessarily need the additional fields? (i.e., the layer and sequence position would be contained in the 'has_part' relationship from the ms object)

{
"type": "CV",
"object": "ARK"
}
]
},
"meta": {
"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"
}
}
102 changes: 47 additions & 55 deletions data-model/SDP-data-model-templates/manuscript-object_sdp-template.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,15 +3,12 @@
"type": "CV",
"shelfmark": "",
"collection": "CV",
"repository": "URI/ARK",
"repository": "URI",
"form": "CV",
"binding": {
"has_binding": "boolean",
"note": [
"array of strings"
],
"features": [
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 think binding features is something we'll implement any time soon?

"array of CV terms"
]
},
"extent": "",
Expand Down Expand Up @@ -40,7 +37,7 @@
},
"events": [
{
"id": "ARK",
"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.

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.

"type": "CV",
"note": [
"array of strings"
Expand All @@ -65,48 +62,30 @@
}
],
"sources": [
"ARK?"
]
}
],
"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.

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.

{
"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": [
{
"entity_type": "CV",
"role": "CV",
"id": "URI/ARK",
"attested_name_NS": "",
"attested_name": "",
"note": [
"array of strings"
]
}
]
}
],
"associated_entities": [
{
"entity_type": "CV",
"relation": "CV",
"id": "URI/ARK",
"note": [
"array of strings"
"ARK/ID of a Paratext? URI of a Zotero Bibl?"
]
}
],
"associated_entities": {
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 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.

"associated_person": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
],
"associated_place": [
{
"relation": "CV",
"id": "URI",
"note": [
"array of strings"
]
}
]
},
"associated_dates": [
{
"date_type": "CV",
Expand Down Expand Up @@ -159,15 +138,28 @@
"viewing_hint": "CV",
"range": "???"
},
"contributor": [
"array of strings (CV)"
],
"related_objects": [
{
"relationship_type": "CV",
"object": "ARK",
"position": "int",
"layer": "int"
}
]
"related_objects": {
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 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.

"has_part": [
{
"type": "CV",
"object": "ARK",
"position": "int",
"layer": "int"
}
]
},
"meta": {
"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"
}
}
Loading