Wikidata talk:WP EMEW/Sources/Burghley Atlas data model
Post questions and comments about the data model for Lord Burghley's Atlas (Q105468439) and its individual pages here!
Properties for the atlas as a whole[edit]
Scripts[edit]
The BL states that the document scripts are secretary hand (Q16933853) and Italic script (Q6093538). Do we have a property to record this, or do we need to request a new property? I don't see anything at Wikidata:WikiProject Books#Manuscript properties. writing system (Q8192) is different (and causes a constraint violation). - PKM (talk) 21:53, 28 February 2021 (UTC)
- Question raised at Wikidata:Project_chat#Script_(style_of_handwriting). - PKM (talk) 20:27, 3 March 2021 (UTC)
- New script style (P9302) has been approved and added to Lord Burghley's Atlas and the subset of maps that BL calls out as having annotations. - PKM (talk) 21:44, 14 March 2021 (UTC)
Has part/part of[edit]
Do we want to record the inverse statements Lord Burghley's Atlas (Q105468439) <has part> [individual map/folio] and [individual map/folio] <part of> Lord Burghley's Atlas (Q105468439)? Or do we just want one direction?
The same question will apply to Atlas of the Counties of England and Wales (Q27919282) and the "work" item for each map. - PKM (talk) 22:29, 28 February 2021 (UTC)
Map editions[edit]
Three of the maps were printed in two "states". These will be represented as two map edition (Q56753859) items marked State I and State II following Skelton. The Burghley maps were sent to him as each map was pulled off the press, and in some cases are different from any final printed map. Should we have a separate "proof of Christopher Saxton's map of [county name]" <instance of> "map edition", or should we treat these as "proof" <of> the earliest edition of each map (=State I or else the only edition)?
- After further thought, I am leaning toward a separate "map edition" for the Burghley proof state and will model it that way. - PKM (talk) 20:16, 2 March 2021 (UTC)
Specific properties for individual pages[edit]
Links to EMEW gazetteer (forthcoming)[edit]
Exact form of EMEW incoming url for a single Saxton map still TBD @Stephen Gadd, eg to be able to see & explore it on CarterGraph with some kind of infobox of metadata, but we have some weeks. Likely to connect to it from Wikidata either by described by source (P1343) = "EMEW" (most probable), with a URL (P2699) qualifier ; possibly also a specific EMEW id for the object. - The previous comment by Jheald via VR project Slack channel, copied and Wikified with permission by PKM (talk) 21:21, 28 February 2021 (UTC)
IIIF manifest[edit]
IIIF manifest can be linked to using IIIF manifest URL (P6108). Some qualifiers may be useful, eg object has role (P3831) = "heavily annotated map manifest"; also something to indicate latest status at that link, eg work in process (Q357662), or a release number ? software version identifier (P348), where we might ask if the word "software" can be dropped from the primary label, also publisher (P123), and for releases with release numbers publication date (P577). For points connected to identifiable places (likely to be ~1000 statements per item) I am thinking to propose a new property "map depicts", so these don't get in the way of regular depicts (P180); so that "depicts" = "Essex", "map depicts"="Colchester", "Great Dunmow", and every last 2-cottage hamlet where an auntie of Saxton once lived. (Would welcome a better name suggestion than "map depicts", that's just the label that first came to mind). It's possible there may be some pushback to the new property proposal & some people will say to just use depicts (P180), but IMO given the volume of statements of this kind we would be adding, it would be good to keep them segregated (and friendlier for the query system).
Qualifiers on "map depicts" would be object named as (P1932), to give the name as transcribed, relative position within image (P2677) , to give a rectangular box for the place on the map, and region within image (P8276) "region within image", for features where we can give a polygon (exact format string for that last maybe to be reviewed, to see what would be easiest for re-use).
In the first instance the "map depicts" statement would be as Structured Data on Commons (SDC), on the Commons-item for an image file of the map uploaded there. But OPEN QUESTION as to what items on Wikidata should also have the "map depicts", possibly with, possible without, the position qualifiers. (individual copy level / edition level / work level &c; or maybe none at all). May depend (i) whether wikidata UI can be made to cope well with so many statements, (ii) To what extent position annotations for one copy of the map can be translated and still work as position annotations for all copies of the map. - The previous comment by Jheald via VR project Slack channel, copied and Wikified with permission by PKM (talk) 21:21, 28 February 2021 (UTC)
- Just to add to the above: new properties for "label position within image" and "point position within image" could also be useful to have on hand. The first would take a string to represent a polygon, to correspond to the 'angled boxes' coming out of Recogito.
- Wikidata:Property proposal/named place on map now marked as 'ready'. Jheald (talk) 09:42, 17 March 2021 (UTC)
Modelling inscriptions[edit]
I've posted several questions relating to modelling inscriptions at Property talk:P1684#Help with modeling inscriptions. I am especially interested in how WD statements for these items can be automatically used to populate the Commons {{Inscription}} template in the future. Comments and suggestions welcome on the Property Talk page. - PKM (talk) 23:51, 8 March 2021 (UTC)
- New Property proposed has graphical element. - PKM (talk) 21:48, 14 March 2021 (UTC)
- Approved as has graphical element (P9344) - PKM (talk) 00:30, 22 March 2021 (UTC)
- All maps in Lord Burghley's Atlas now have their Latin inscriptions and graphical elements modeled. - PKM (talk) 22:08, 31 March 2021 (UTC)