Agents

[RGShepherd]

OK! First of all:

• Generally:
  • I think the value of type must be either Person or Group - see Types. This can be deduced from the value of @datatype.actual, which will be "Individual" or "Organisation".
  • Shouldn't we also model Life Events, as per the birth, date, and death blocks in the Elasticsearch?
  • I don't suppose Linked Art allows us to distinguish between name formats, i.e. display versus sort order?
  • Should identified_by.content for PIDs not also contain our base URL?
  • referred_to_by for Brief texts:
  • data is repeating. Where description.source:"TMS", only use the value where description.status:"Active". If there are more than one of these, it's our fault 😉
  • Should we map these instead as Biographies?
• agent-1007.json:
  • Can an agent really have a current_owner or a current_custodian? (I see this is missing from agent-1184 and others.)
• agent-2945:
  • I'd like to think he could be modelled as a member of a group (the NG); but alas, no data in the endpoints ...
• agent-7983:
  • We've got quite a few more possible referred_to_by Linguistic Objects in the notes area of the Elasticsearch - do you think they're worth including?
  • Could we add the external identifiers (identifier.type:"PID (external)") as Equivalent Resources?

[richardofsussex]

I've been through the comments above, and taken action where possible/appropriate. I originally mapped agents using Jolt, so there were some points of difference. I noticed that I had also previously mapped parts of names, so those are now restored in the XSLT-driven version.

The identified_by.content for PIDs I had seen as an informational thing rather than a Linked Data URL, so I have left it as found. (We need in any case to have a discussion about the format of NG LD URLs. Maybe we should start by rattling Rob Sanderson's cage and see what he has to say about entity type within the URL.)

Notes (as in 7983) are included, but I have specified their type as the one in the ES output, not LinguisticObject. Good idea/ bad idea? (I could easily make this into an array and include them both, but that would change the structure of the output - a feature of JSON which I hate.)

I've then re-run 'blind' the seven agents identified as test cases. They are in e.g. http://richardofsussex.me.uk/ng/ciim7-output/agent-7983.json. Please have a look through and report back on further issues, backsliding, etc.

Thanks

[RGShepherd]

@richardofsussex, thanks - looking good! Just a couple of comments:

1. Life events: surely Linked Art can find a better way to include life (as opposed to active) dates which are expressed as a string than the carried_out block?
2. Looking at name parts, this is where our specific implementation of TMS bites us on the backside. Never mind - we shall output the data as is and see what transpires. Might encourage us to have a rethink.
3. Unless it's required, we should probably drop equivalent._label: I have no idea what the preferred term in any of the external sources is.
4. referred_to_by: dammit - forgot everything else that was in note! Probably best to restrict these to blocks where note.project:"lbso" for now.

[richardofsussex]

In agent-1184, there is an "active 1278; died 1318" - but then the birth section also says 1278 (without qualification). So what ground truth are we to deduce from this?

[richardofsussex]

On your third point, _label is meant to be a useful indicator for a programmer, etc., and all the Linked Art examples include it. My inclination is to leave it as it currently is: nothing is harmed by its presence.

[richardofsussex]

Added test for note.project"lbso": see http://richardofsussex.me.uk/ng/ciim7-output/agent-7983.json

[jpadfield]

Some of these comments mirror @RGShepherd comments above, but I have left them in as they flag issues are still current as of the file I checked today:

1. no defined ID in the JSON file - need to add it based on the PID - it is good to keep the reference to the PID as is, but we also need to have the ID defined for the agent. Yes the IDs should resolve, which they may not yet, but for this mapping process the IDs should be included.
2. Label including the term "Individual" as well as the name is odd - is this for a programming reason - I could not see it in the LA examples at all?
3. the use of type:Type seems overkill, but this does follow the LA examples.
4. the initial "classified_as" seems overly complex or wrong - nested types and linguistic object use odd??
5. inverted_terms use - is this specific enough - will this value be used for ordering by family name, etc .... can we be more specific in describing its purpose, do we want to be?
6. "born" and "died" need to go to an event, with a type, which then has a timespan.
7. timespans have a "note" for the display date, but this perhaps should be a _label?
8. need to check the links for the refereed to text - the linguistic object can have multiple types, not nesting aat types? We also may have duplication of data such as type - Type relationships for the AAT nodes ( the web text seems to be in there twice )
9. The identity of the final 3 LObjs is unclear - can we say what they are and what they are for at all?

[RGShepherd]

Taking @jpadfield's comments in order:

1. Agreed. Applies to all Linked Art outputs.
2. Agreed - as per https://github.com/national-gallery/NG-CIIM/issues/19#issuecomment-1674542826.
3. That's how Linked Art rolls ...
4. I don't think we need classified_as in this context - the content is instead used to populate to type.
5. http://vocab.getty.edu/page/aat/300404672 gives the definition 'Multiple-word terms or names that are arranged in the form used in back-of-book indexing or other similar situations. Examples are Wren, Christopher and buttresses, flying. Distinguished from natural order terms or names.' So it's an accurate description of what the content is (derived from the TMS AlphaSort field, which contains the name formatted to sort alphabetically by family name). There doesn't seem to be a suitable alternative in the AAT hierarchy.
6. We have a problem with our source data (see @richardofsussex's https://github.com/national-gallery/NG-CIIM/issues/20#issuecomment-1668344775): TMS records start and end dates for people/organisations, but has no means of characterising them as birth / baptism / active etc. So without some very complex parsing of date strings (as opposed to values), we have no way of being able to see that these are birth / death dates - significant given Linked Art's distinction between life dates and active dates.
7. Linked Art doesn't seem clear here. https://linked.art/example/event/3.json uses timespan._label, whereas https://linked.art/example/event/4.json uses timespan.identified_by.content. Neitehr use note, though. _label's probably more straightforward?
8. Nested linguistic_objects match https://linked.art/example/object/24.json; but I note that our lbso-derived referred_to_bys lack type:"LinguisticObject" - @richardofsussex , please could you add them? Web texts are no longer duplicated: see http://richardofsussex.me.uk/ng/ciim7-output/agent-7983.json
9. @jpadfield , can't see what you're referring to here. Which record, which Linguistic Objects?

[richardofsussex]

OK, if you check http://richardofsussex.me.uk/ng/ciim7-output/agent-7983.json you'll see that I have addressed points 1, 2 and 4. (The absence of Id was a silly bug: I was testing for 'linked-data' instead of 'linked-art' - an easy mistake to make.) The resolution of 4 leaves another empty json set, so the same question over whether I should vigorously suppress these applies. Also, I'm assuming that you never want the @datatype.actual value output as a classification.

I'll get back to the other issues later.

[jpadfield]

4. We can classify the agent as an "individual", but that should be a straight link to an AAT term (or similar), my issue was with the further connection to the "titles/names" aat term.
5. I agree that the AAT term matches the data, I was just wondering what the data was for - if we list the Family Name and the Given Name people an order agents as needed. Including the values for a "inverted terms" is fine, I was just wondering on the use case and if it would be a useful and meaningful additional term.
6. Understood issues of source data - but if we do have values that we model as timespans connected via a "born" type relationship we need include the blank-node for the event to match the LA model. As far as the parsing the dates are concerned I did do this years ago and yes it is a big pile of regular expressions, designed to identify the dates and the types of events, etc. I have shared this with you before but we have not spoken about it in a while. I would have to check if any of my old TMS queries still apply it ....
7. If we are including a simple display text for a date lets use _label, if we do have additional information quantifiers etc, then we could also include a note ...
8. The output seems to have a LO that is classified_as an AAT term, but then the AAT term is subsequently classified_as another AAT term. If we want to include both of these aat terms then they both need to be connected to the LO not to one another.
9. was in relation to the final 3 "subject_of" relationships that all point to things with ng:PID IDs that are described simply as LOs with a label

@richardofsussex I am not sure what you means by "another empty json set" ?

[jpadfield]

@RGShepherd the last three things I was referring to as LOs are:

flowchart TB
classDef object stroke:#2C5D98,fill:#2C5D98,color:white,rx:5px,ry:5px;
classDef url stroke:#2C5D98,fill:white,color:#2C5D98,rx:5px,ry:5px;
classDef actor2 stroke:black,fill:#FFBDCA,color:black,rx:20px,ry:20px;
classDef classstyle stroke:black,fill:white,color:black,rx:5px,ry:5px;
classDef infoobj stroke:#907010,fill:#fffa40,color:black,rx:20px,ry:20px;
classDef literal stroke:black,fill:#f0f0e0,color:black,rx:2px,ry:2px,max-width:100px;

O0("This Model")
class O0 object;

O1("https://linked.art/ns/v1/linked-art.json")
class O1 url;
click O1 "https://linked.art/ns/v1/linked-art.json"
O0["This Model"] ---->|has context|O1["https://linked.art/ns/v1/linked-art.json"]

O2("_#-0")
class O2 actor2;

O3("Person")
class O3 classstyle;
O2["_"] ---->|type|O3["Person"]

O4("ng:0E4I-0008-0000-0000")
class O4 infoobj;
click O4 "https://data.ng-london.org.uk/0E4I-0008-0000-0000" "Link to: https: ..."; 
click O4 "https://data.ng.ac.uk/0E4I-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["_"] ---->|subject_of|O4["ng:0E4I-0008-0000-0000"]

O5("LinguisticObject")
class O5 classstyle;
click O4 "https://data.ng.ac.uk/0E4I-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O4["ng:0E4I-0008-0000-0000"] ---->|type|O5["LinguisticObject"]

O6("#34;Allgemeines Lexikon die bildenden K\u00fcnstler: von der Antike bis zur Gegenwart#34;")
class O6 literal;
click O4 "https://data.ng.ac.uk/0E4I-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O4["ng:0E4I-0008-0000-0000"] ---->|_label|O6["#34;Allgemeines Lexikon die bildenden K\u00fcnstler: von der<br/>Antike bis zur Gegenwart#34;"]

O7("ng:0DWD-0008-0000-0000")
class O7 infoobj;
click O7 "https://data.ng-london.org.uk/0DWD-0008-0000-0000" "Link to: https: ..."; 
click O7 "https://data.ng.ac.uk/0DWD-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["_"] ---->|subject_of|O7["ng:0DWD-0008-0000-0000"]
click O7 "https://data.ng.ac.uk/0DWD-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O7["ng:0DWD-0008-0000-0000"] ---->|type|O5["LinguisticObject"]

O8("#34;Ludolf Backhusen (Emden 1630 - Amsterdam 1708)#34;")
class O8 literal;
click O7 "https://data.ng.ac.uk/0DWD-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O7["ng:0DWD-0008-0000-0000"] ---->|_label|O8["#34;Ludolf Backhusen (Emden 1630 - Amsterdam 1708)#34;"]

O9("ng:0E2V-0008-0000-0000")
class O9 infoobj;
click O9 "https://data.ng-london.org.uk/0E2V-0008-0000-0000" "Link to: https: ..."; 
click O9 "https://data.ng.ac.uk/0E2V-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O2["_"] ---->|subject_of|O9["ng:0E2V-0008-0000-0000"]
click O9 "https://data.ng.ac.uk/0E2V-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O9["ng:0E2V-0008-0000-0000"] ---->|type|O5["LinguisticObject"]

O10("#34;Ludolf Bakhuizen#34;")
class O10 literal;
click O9 "https://data.ng.ac.uk/0E2V-0008-0000-0000" "Link to: https://data.ng.ac.uk ..."; 
O9["ng:0E2V-0008-0000-0000"] ---->|_label|O10["#34;Ludolf Bakhuizen#34;"]
;

[RGShepherd]

1. Resolved.
2. Resolved.
3. Resolved.
4. @jpadfield , please can you be more precise about where you are in the document tree? I think you mean identified_by.classified_as, which is there because we have (looking at http://richardofsussex.me.uk/ng/ciim7-output/agent-7983.json) three identified_by.names, all of different types: a non-preferred one (titles/names), a preferred one (Primary Name), and one in inverted order (inverted terms). We use classified_by here to distinguish between the types, with the output structured exactly as per https://linked.art/example/person/3.
5. Well, if you want names in sortable order, you could either write your own concatenation function trying to second-guess exactly how different names should concatenate the individual components, or you could just use the value of identified_by.content where name.classified_as.id:"http://vocab.getty.edu/aat/300404672". I know which I'd rather do.
6. What blank node for an event? Our model matches https://linked.art/example/person/8 exactly, AFAICT.
7. Let's just stick with _label for now.
8. Our output matches the structure of https://linked.art/example/person/10, so I can't see what the problem is here.
9. These are publications about the person in question, identified by their PIDs and titles. In the absence of any guidance in the Linked Art model documentation for linking entities to publications about them, this seems a reasonable mapping.

[jpadfield]

4: A simplified version of the first few relationships for agent 1007 can be seen below:

flowchart TB
classDef object stroke:#2C5D98,fill:#2C5D98,color:white,rx:5px,ry:5px;
classDef url stroke:#2C5D98,fill:white,color:#2C5D98,rx:5px,ry:5px;
classDef actor2 stroke:black,fill:#FFBDCA,color:black,rx:20px,ry:20px;
classDef classstyle stroke:black,fill:white,color:black,rx:5px,ry:5px;
classDef literal stroke:black,fill:#f0f0e0,color:black,rx:2px,ry:2px,max-width:100px;
classDef type2 stroke:red,fill:#FAB565,color:black,rx:20px,ry:20px;

O0("This Model")
class O0 object;

O1("https://linked.art/ns/v1/linked-art.json")
class O1 url;
click O1 "https://linked.art/ns/v1/linked-art.json"
O0["This Model"] ---->|has context|O1["https://linked.art/ns/v1/linked-art.json"]

O2("_#-0")
class O2 actor2;

O3("Person")
class O3 classstyle;
O2["_"] ---->|type|O3["Person"]

O4("#34;Individual:  Ludolf Bakhuizen#34;")
class O4 literal;
O2["_"] ---->|_label|O4["#34;Individual:  Ludolf Bakhuizen#34;"]

O5("_#-1")
class O5 type2;
O2["_"] ---->|classified_as|O5["_"]

O6("LinguisticObject")
class O6 classstyle;
O5["_"] ---->|type|O6["LinguisticObject"]

O7("aat:300435445")
class O7 type2;
click O7 "http://vocab.getty.edu/aat/300435445" "Link to: http://vocab.getty.edu ..."; 
click O7 "http://vocab.getty.edu/aat/300435445" "Link to: http://vocab.getty.edu/aat ..."; 
O5["_"] ---->|classified_as|O7["aat:300435445"]

O8("Type-8")
class O8 classstyle;
click O7 "http://vocab.getty.edu/aat/300435445" "Link to: http://vocab.getty.edu/aat ..."; 
O7["aat:300435445"] ---->|type|O8["Type"]

O9("#34;titles\/names#34;")
class O9 literal;
click O7 "http://vocab.getty.edu/aat/300435445" "Link to: http://vocab.getty.edu/aat ..."; 
O7["aat:300435445"] ---->|_label|O9["#34;titles\/names#34;"]

O10("#34;Individual#34;")
class O10 literal;
O5["_"] ---->|content|O10["#34;Individual#34;"]
;

The agent is classified as an individual, via a blank node, I guess as there is no AAT term for individual, but then this blank node is then classified as via another aat term (titles/names) which does not make sense.

If we wanted to stick to this sort of structure I would think the following would make more sense:

flowchart TB
classDef object stroke:#2C5D98,fill:#2C5D98,color:white,rx:5px,ry:5px;
classDef url stroke:#2C5D98,fill:white,color:#2C5D98,rx:5px,ry:5px;
classDef actor2 stroke:black,fill:#FFBDCA,color:black,rx:20px,ry:20px;
classDef classstyle stroke:black,fill:white,color:black,rx:5px,ry:5px;
classDef literal stroke:black,fill:#f0f0e0,color:black,rx:2px,ry:2px,max-width:100px;
classDef type2 stroke:red,fill:#FAB565,color:black,rx:20px,ry:20px;

O0("This Model")
class O0 object;

O1("https://linked.art/ns/v1/linked-art.json")
class O1 url;
click O1 "https://linked.art/ns/v1/linked-art.json"
O0["This Model"] ---->|has context|O1["https://linked.art/ns/v1/linked-art.json"]

O2("_#-0")
class O2 actor2;

O3("Person")
class O3 classstyle;
O2["_"] ---->|type|O3["Person"]

O4("#34;Individual:  Ludolf Bakhuizen#34;")
class O4 literal;
O2["_"] ---->|_label|O4["#34;Individual:  Ludolf Bakhuizen#34;"]

O5("_#-1")
class O5 type2;
O2["_"] ---->|classified_as|O5["_"]

O6("Type-6")
class O6 classstyle;
O5["_"] ---->|type|O6["Type"]

O7("aat:300024979")
class O7 type2;
click O7 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu ..."; 
click O7 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu/aat ..."; 
O5["_"] ---->|equivalent|O7["aat:300024979"]

O8("Type-8")
class O8 classstyle;
click O7 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu/aat ..."; 
O7["aat:300024979"] ---->|type|O8["Type"]

O9("#34;people (agents)#34;")
class O9 literal;
click O7 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu/aat ..."; 
O7["aat:300024979"] ---->|_label|O9["#34;people (agents)#34;"]

O10("#34;Individual#34;")
class O10 literal;
O5["_"] ---->|content|O10["#34;Individual#34;"]
;

Note that the initial blank node is now equivalent to a relevant AAT term and it is also typed as a Type.

Alternatively we could just go for:

flowchart TB
classDef object stroke:#2C5D98,fill:#2C5D98,color:white,rx:5px,ry:5px;
classDef url stroke:#2C5D98,fill:white,color:#2C5D98,rx:5px,ry:5px;
classDef actor2 stroke:black,fill:#FFBDCA,color:black,rx:20px,ry:20px;
classDef classstyle stroke:black,fill:white,color:black,rx:5px,ry:5px;
classDef literal stroke:black,fill:#f0f0e0,color:black,rx:2px,ry:2px,max-width:100px;
classDef type2 stroke:red,fill:#FAB565,color:black,rx:20px,ry:20px;

O0("This Model")
class O0 object;

O1("https://linked.art/ns/v1/linked-art.json")
class O1 url;
click O1 "https://linked.art/ns/v1/linked-art.json"
O0["This Model"] ---->|has context|O1["https://linked.art/ns/v1/linked-art.json"]

O2("_#-0")
class O2 actor2;

O3("Person")
class O3 classstyle;
O2["_"] ---->|type|O3["Person"]

O4("#34;Individual:  Ludolf Bakhuizen#34;")
class O4 literal;
O2["_"] ---->|_label|O4["#34;Individual:  Ludolf Bakhuizen#34;"]

O5("aat:300024979")
class O5 type2;
click O5 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu ..."; 
click O5 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu/aat ..."; 
O2["_"] ---->|classified_as|O5["aat:300024979"]

O6("Type-6")
class O6 classstyle;
click O5 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu/aat ..."; 
O5["aat:300024979"] ---->|type|O6["Type"]

O7("#34;people (agents)#34;")
class O7 literal;
click O5 "http://vocab.getty.edu/aat/300024979" "Link to: http://vocab.getty.edu/aat ..."; 
O5["aat:300024979"] ---->|_label|O7["#34;people (agents)#34;"]
;

[RGShepherd]

4: A simplified version of the first few relationships for agent 1007 can be seen below:

But it's not rendering ...

[jpadfield]

Sorry cache error - all three working now

[RGShepherd]

But this has all been resolved: https://github.com/national-gallery/NG-CIIM/issues/20#issuecomment-1674648084

[jpadfield]

5: I think this one is perhaps for documentation - it was just a thought that we might be able to flag the purpose of the inverted term was to facilitate name ordering by family name - I do not have an issue with the AAT term, which is correct, I was just wondering if we could make it more obvious for users in the future. But as noted this is perhaps best covered in worked examples within documentation.

6: https://linked.art/example/person/8 maps to:

flowchart TB
classDef object stroke:#2C5D98,fill:#2C5D98,color:white,rx:5px,ry:5px;
classDef url stroke:#2C5D98,fill:white,color:#2C5D98,rx:5px,ry:5px;
classDef actor2 stroke:black,fill:#FFBDCA,color:black,rx:20px,ry:20px;
classDef classstyle stroke:black,fill:white,color:black,rx:5px,ry:5px;
classDef literal stroke:black,fill:#f0f0e0,color:black,rx:2px,ry:2px,max-width:100px;
classDef event2 stroke:blue,fill:#96e0f6,color:black,rx:20px,ry:20px;
classDef timespan stroke:blue,fill:#ddfffe,color:black,rx:20px,ry:20px;
classDef place2 stroke:#3a7a3a,fill:#aff090,color:black,rx:20px,ry:20px;

O0("This Model")
class O0 object;

O1("https://linked.art/ns/v1/linked-art.json")
class O1 url;
click O1 "https://linked.art/ns/v1/linked-art.json"
O0["This Model"] ---->|has context|O1["https://linked.art/ns/v1/linked-art.json"]

O2("lae:person/8")
class O2 actor2;

O3("Person")
class O3 classstyle;
click O2 "https://linked.art/example/person/8" "Link to: https://linked.art/example/person ..."; 
O2["lae:person/8"] ---->|type|O3["Person"]

O4("#34;Amanda B. Curtlett#34;")
class O4 literal;
click O2 "https://linked.art/example/person/8" "Link to: https://linked.art/example/person ..."; 
O2["lae:person/8"] ---->|_label|O4["#34;Amanda B. Curtlett#34;"]

O5("_#-0")
class O5 event2;
click O2 "https://linked.art/example/person/8" "Link to: https://linked.art/example/person ..."; 
O2["lae:person/8"] ---->|born|O5["_"]

O6("Birth")
class O6 classstyle;
O5["_"] ---->|type|O6["Birth"]

O7("_#-1")
class O7 timespan;
O5["_"] ---->|timespan|O7["_"]

O8("TimeSpan")
class O8 classstyle;
O7["_"] ---->|type|O8["TimeSpan"]

O9("1767-01-09")
class O9 literal;
O7["_"] ---->|begin_of_the_begin|O9["1767-01-09"]

O10("1767-01-12")
class O10 literal;
O7["_"] ---->|end_of_the_end|O10["1767-01-12"]

O11("_#-2")
class O11 event2;
click O2 "https://linked.art/example/person/8" "Link to: https://linked.art/example/person ..."; 
O2["lae:person/8"] ---->|died|O11["_"]

O12("Death")
class O12 classstyle;
O11["_"] ---->|type|O12["Death"]

O13("_#-3")
class O13 timespan;
O11["_"] ---->|timespan|O13["_"]
O13["_"] ---->|type|O8["TimeSpan"]

O14("1824-08-21")
class O14 literal;
O13["_"] ---->|begin_of_the_begin|O14["1824-08-21"]
O13["_"] ---->|end_of_the_end|O14["1824-08-21"]

O15("_#-4")
class O15 place2;
O11["_"] ---->|took_place_at|O15["_"]

O16("Place")
class O16 classstyle;
O15["_"] ---->|type|O16["Place"]

O17("#34;Death Place#34;")
class O17 literal;
O15["_"] ---->|_label|O17["#34;Death Place#34;"]
;

As you can see there are additional nodes between the person and the time span, these are the events with type Birth and Death. They are also shown in the documentation : https://linked.art/model/actor/#birth-and-death-formation-and-dissolution - this one also includes an event location but we do not have that as data just now.

7: Ok.

8: This one may well be a question for linked art then, classifying an existing term seems very odd, the logic would seem to be that the LO is a Bio statement and and Brief Text, not that the the term "Bio Statement" is also a "Brief Text" ....

9: Could we just add a "classified_as" an aat:300111999 - publications (documents) statement? What is there is not wrong it just seemed incomplete not to let people know.

[jpadfield]

But this has all been resolved: #20 (comment)

Sorry, I was just responding to your comment - I see @richardofsussex mentions my point 4 but I did not see an answer, I did ask a followup about is comment.

Based on your comment it would seem like the additional classified_as has been attached to the wrong node, which I guess would what @richardofsussex was going to fix?

But as long as he has caught it then all good :-)

[RGShepherd]

6. OK. We have:

   "born": [
   {
   "type": "TimeSpan",
   "begin_of_the_begin": "1630-01-01T00:00:00Z",
   "end_of_the_end": "1630-12-31T23:59:59Z",
   "note": "1630"
   }
   ]

   but we need:

   "born": [
   {
   "type": "Birth",
   "timespan": {
     "type": TimeSpan",
     "begin_of_the_begin": "1630-01-01T00:00:00Z",
     "end_of_the_end": "1630-12-31T23:59:59Z",
     "note": "1630"
   }
   }
   ]

7. Resolved.
8. Linked Art compliant, so resolved as far as we're concerned.
9. Seems sensible: for our publication references, please add classified_as.id:"http://vocab.getty.edu/aat/300111999" with ...._label:"publications (documents)"

[jpadfield]

Agent 7983 (not duplicating comments already given for 1007

10. There is an issue with the text of the "slavery connections" research note. There is a URL in the text which is fine, but it begins with a "<", which is then not closed - this can cause problems with any web based presentation - is this due to some aspect of processing or is it in the original text?
11. makes use of the predicate "referred-to-by" - should be "referred_to_by" or has something changed?
12. for the equivalent ID - having _label and type seems to be standard - (though type seems overkill as we already have it on the source entity) - what is the thinking about all of the additional links, to LOs labelling the source of the external IDs - do we have a use case for this information - could the information not be easily determined form the external IDs urls?

I got side tracked at this stage and the JSON file seems to have been replaced by an elastic search output again now - I will carry on looking next week

[RGShepherd]

10. Looks closed to me: (Information taken from Nick Draper, 'The fall of slavery: statues, symbols and social contention', History & Policy [online], London, 10 June 2020, <http://www.historyandpolicy.org/opinion-articles/articles/the-fall-of-slavery-statues-symbols-and-social-contention> accessed 24 May 2021.)
11. equivalent.referred-to-by does look like a typo, @richardofsussex ...
12. IIRC, it's there in the data and @richardofsussex thought it was useful to retain it as it removes the need to parse a URL.

[richardofsussex]

OK, I think I've sorted out the birth and death structures. See http://richardofsussex.me.uk/ng/ciim7-output/agent-1007.json or http://richardofsussex.me.uk/ng/ciim7-output/agent-7983.json: please confirm.

[richardofsussex]

Incidentally, birth and death can either be arrays or simple maps. In the LA examples they tend to be maps; I have arrays, to allow for the possibility of multiple opinions on this event. Is this something we have a choice over, i.e. does the LA model mandate which we should use? I can't work that out from the information in the context document.

[richardofsussex]

I think Joe was taking issue with the LA "type of a type" mechanism, which I agree is verbose and strange, but which is their solution to the otherwise intractable problem of implementing ".1" relationships, which are integral to the CIDOC CRM model but cannot be expressed naturally in RDF. Or have I missed his point?

Are there any other issues which remain unresolved from the blizzard of comments yesterday?

[jpadfield]

@richardofsussex yes it was the types-of-types - I can see what they have tried to do, but logic is not consistent, I was emailing about something else so I have asked a question about it. But yes at the moment it does follow the documentation.

The issue of applying properties to triples has been examined in RDF* but I have never really explored it.

Were you going to add a classified_as to the publications, for example in 1007?

[jpadfield]

10. Looks closed to me: (Information taken from Nick Draper, 'The fall of slavery: statues, symbols and social contention', History & Policy [online], London, 10 June 2020, <http://www.historyandpolicy.org/opinion-articles/articles/the-fall-of-slavery-statues-symbols-and-social-contention> accessed 24 May 2021.)

It is not great to have "<>" in a string like that but I have fixed the issue on my end to cope with them. Are they there for a reason, do they come from something else?

12. IIRC, it's there in the data and @richardofsussex thought it was useful to retain it as it removes the need to parse a URL.

The LA examples do not seem to have this, but I have only looked through a few recently, but we can have them if they are useful. We should probably be consistent with this type of thing if we can, so we can come up with some additional rules of extra things we add on ...

[RGShepherd]

Are there any other issues which remain unresolved from the blizzard of comments yesterday?

I believe this is where we are:

1. Resolved.
2. Resolved.
3. Resolved.
4. Resolved.
5. Resolved.
6. Resolved.
7. Resolved.
8. Resolved.
9. To do: for our publication references, please add classified_as.id:"http://vocab.getty.edu/aat/300111999" with ...._label:"publications (documents)"
10. Resolved.
11. To do: please change equivalent.referred-to-by to equivalent.referred_to_by.
12. Resolved.

[RGShepherd]

Incidentally, birth and death can either be arrays or simple maps. In the LA examples they tend to be maps; I have arrays, to allow for the possibility of multiple opinions on this event. Is this something we have a choice over, i.e. does the LA model mandate which we should use? I can't work that out from the information in the context document.

Ha! except that I think they should be maps; differences of opinion would be managed by assertions, if I've understood correctly. Perhaps @jpadfield could confirm? If so, then we would also have a new

13. Convert birth / death arrays to maps.

[richardofsussex]

I've dealt with 9, 11 and 13: please check and confirm this example agent: http://richardofsussex.me.uk/ng/ciim7-output/agent-7983.json. I'll re-process the other agents in due course. ... Now done

[RGShepherd]

Agreed - I think everything is now resolved for agents.

[RGShepherd]

A note that agent-agent relationships exist in the TMS CIIM views, and are on the roadmap for incorporation into the agent $.agents and $.parents blocks in the new year.