Example/pr blanknodes

[coret]

Ja, ik denk een goed goed advies (alhoewel we in de discussie over het model de voorkeur hadden om geen blank nodes te gebruiken).

Ik heb dit nu ook bij de WO2slachtoffers op Genealogie Online geïmplementeerd, via bijv. https://www.genealogieonline.nl/wo2slachtoffers/23.ttl zie je een reconstructie op basis van meerdere observaties.

T.a.v. @prefix pico: <https://ontology.personsincontext.org/>, zodra de URI voor het model is vastgesteld moeten dit soort niet bestaande URI's in heel de repo gewijzigd worden voor ze hergebruikt worden door copy/paste acties.

[pwoltjer]

Mooi dat je dit meteen hebt uitgewerkt, Ivo. Het ziet er goed uit. Ik heb één opmerking/aanvulling:

Een A2A record bevat altijd een identifier van een Person, die uniek is binnen dat A2A record. Het is waardevol om te weten welke Person uit het A2A record is gebruikt voor de pico:PersonReconstruction.

Daarom zou ik de Person Identifier graag toevoegen aan het voorbeeld. Zo bijvoorbeeld? :

    prov:wasDerivedFrom [
      a pico:PersonObservation ;
      sdo:identifier "Person01" ;
      pico:hasPrimarySource [
        a schema:ArchiveComponent ;
        schema:url <https://allefriezen.nl/zoeken/deeds/573ace76-6f44-389f-666d-4c81bb13ed88> 
      ] ;
    ] ;

[coret]

Ik twijfel over het opnemen van de person identifier, want wie heeft hier iets aan?

• Een machine kan niet zo veel met een literal, zeker omdat deze alleen betekenis heeft binnen het A2A record en de URI van dat A2A record (https://webservices.picturae.com/a2a/b3d793d4-f737-11e5-903e-60f81db16928?verb=GetRecord&metadataPrefix=oai_a2a&identifier=573ace76-6f44-389f-666d-4c81bb13ed88) is niet opgenomen.
• Een mens heeft ook niets aan deze identifier, want deze wordt in de interface (via schema:url) https://allefriezen.nl/zoeken/deeds/573ace76-6f44-389f-666d-4c81bb13ed88 niet getoond.

PS. 'Person01' is geen identifier in het voorbeeld A2A record, zie ook https://www.openarchieven.nl/frl:573ace76-6f44-389f-666d-4c81bb13ed88/xml

[pwoltjer]

Ik begrijp je twijfels, maar ik denk dat het toch nuttig is om de pid van de A2A Person op te slaan.

Intern hebben wij het nodig voor de communicatie tussen het systeem dat onze Persoonsreconstructies maakt en onze beheeromgeving. Alleen de eerste bevat gegevens over de Persoonsvermeldingen (in PiCo óf in A2A formaat). Als ik de Person pid opneem in de beheeromgeving, kan ik die beschouwen als de single source of truth voor de Persoonsreconstructie. En dat wil ik ook. Het systeem dat de website bouwt kan dan bij elke Persoonsreconstructie ook de gegevens van de juiste Persoonsvermelding ophalen.

Dat kunnen we natuurlijk beschouwen als een interne aangelegenheid. Dan doen wij het wel, maar nemen het niet op in de PiCo standaard. We kunnen er zelfs voor kiezen om de Person pid niet mee te nemen in de RDF versie van de Persoonsreconstructie. Maar...

Als een archief dan wil weten of een bepaalde Persoon uit hun A2A collectie voorkomt in één van onze Persoonsreconsctructies dan kan hij die niet vinden... (Hij vindt dan immers alle persoonsreconstructie die persoonsvermeldingen bevatten die op dezelfde akte staan.)

En nog iets: als een archiefinstelling later over gaat van A2A naar PiCo, dan zou het heel fijn zijn als ze ergens in hun PiCo Persoonsvermelding de oude identifier opnemen. Als dat een combinatie is van de SourceDigitalOriginal en de pid van de Person kunnen wij in onze beheeromgeving de bestaande Persoonsreconstructie omtoveren zodat hij verwijst naar de nieuwe Persoonsvermelding URI.

Daarom pleit ik er toch voor om het op te nemen in het voorbeeld. Op die manier doet iedereen het straks (hopelijk) op dezelfde manier. En als straks helemaal niemand meer A2A gebruikt, haal ik het er weer uit. Dan zijn we sowieso van die blank note af. Hoera!

[ivozandhuis]

Wat mij betreft hebben jullie natuurlijk allebei gelijk :-) Ik begrijp de use case van Pieter heel goed. Hij is bovendien vrij om PiCo uit te breiden naar eigen inzicht en use case. En dan is sdo:identifier een goede keuze. Het is de manier waarop hij zelf data publiceert, dus het stelt geen extra eisen aan instellingen die PersonObservations publiceren. Ten slotte: door sdo:identifier in het voorbeeld op te nemen helpt het mensen hopelijk begrijpen dat ze uiteindelijk afzonderlijke PersonObservations moeten publiceren en niet alleen maar bronnen. Ik voeg de sdo:identifier in het voorbeeld toe, maar pleit er net als Bob voor om het dan uit te breiden met de identifier van de bron, zodat deze uniek wordt in hele graaf. Daarnaast stel ik voor ook Bob's voorbeeld op te nemen als voorbeeld zonder identifier, zodat men kan zien dat het ook zonder kan.