pvdbosch
commented
4 years ago Some prior discussion in https://fedictaim.atlassian.net/wiki/spaces/JCSP/pages/1887174735/2020-04-24+Meeting+notes#Identifiers (access required)
and below (extract from mails between me and @barthanssens ) :
Om dan aan de behoeften te voldoen van dat voorbeeldgeval, lijkt me dan dat dcterms:type voor “identifier type” in de adms:Identifier ook moet gedefinieerd worden:
http://www.example.com/Bart a person:Person ; adms:identifier http://id.rrn.fgov.be/77010112345 ; adms:identifier http://id.bosa.be/staff/xyz .
http://id.rrn.fgov.be/77010112345 a adms:Identifier ; skos:notation “77.01.11-123.45” ; adms:schemaAgency “Rijksregister”@nl ; dcterms:issued “1977-01-12 12:00:00” . dcterms:type http://rrn.fgov.be/datatype/rrnumber .
http://id.bosa.be/staff/xyz a adms:Identifier; skos:notation “XYZ” ; adms:schemaAgency “Personeelsdienst BOSA”@nl ; dcterms:issued “2019-03-01 09:00:00” ; dcterms:type http://bosa.belgium.be/datatype/personeelsnummer .
Als er een Class zou bestaan specifiek voor rijksregisterpersonen zou die misschien gebruikt kunnen worden als waarde (deze bestaat nog niet), bvb:
http://id.rrn.fgov.be/77010112345 a adms:Identifier ; … dcterms:type http://vocab.belgif.be/ns/person#BelgianResident
met dan
http://vocab.belgif.be/ns/person#BelgianResident a rdfs:Class rdfs:subClassOf http://vocab.belgif.be/ns/person#Resident
Hallo Peter,
Core Person, en ook wat oorspronkelijk Core Business was nu W3C Registered Organization Vocabulary (ROV), maken inderdaad gebruik van ADMS (zie ook https://www.w3.org/TR/vocab-regorg/)
Merk wel op dat adms:Identifier (met hoofdletter) een class is, geen property. De property adms:identifier (kleine letter), verwijst naar een Identifier class.
En inderdaad, die gebruiken geen dcterms:identifier om de ID te stockeren, maar wel allebei skos:notation (dus geen aparte organizationID en personID)
Het idee van ADMS is wel flexibel natuurlijk: men gaat er terecht van uit dat een ID toegekend wordt door iets of iemand, en bijgevolg zijn er ook meerdere IDs mogelijk voor dezelfde persoon (een rijksregisternummer en een persooneelsnummer bijvoorbeeld) of organisatie. En op een bepaalde datum etc
ADMS laat toe om dit te capteren, en dan krijg je dus een persoon die 1 of meerdere ADMS Identifiers heeft, die elk skos:notation property gebruiken
http://www.example.com/Bart a person:Person ; adms:identifier http://id.rrn.fgov.be/77010112345 ; adms:identifier http://id.bosa.be/staff/xyz .
http://id.rrn.fgov.be/77010112345 a adms:Identifier ; skos:notation “77.01.11-123.45” ; adms:schemaAgency “Rijksregister”@nl ; dcterms:issued “1977-01-12 12:00:00” .
http://id.bosa.be/staff/xyz a adms:Identifier; skos:notation “XYZ” ; adms:schemaAgency “Personeelsdienst BOSA”@nl ; dcterms:issued “2019-03-01 09:00:00” .
Mvg,
Bart
In the list of vocabularies, every notion is identified by its own URI except for identifiers types.
For instance: ssin, employerId and nssoNumber all have the URI http://purl.org/dc/terms/identifier, but there’s no way to refer to these notions with their own URI; which was the whole idea of introducing URIs in the vocabularies. These identifiers are used outside digital context (id card, entry forms, documents, ...) and have semantics associated to them.
Currently, when using the generic URI in Linked Data, we would lose the semantics about the specific type of identifier; so we should find a way to distinguish them. This is important in contexts where multiple identifiers can be used for the same entity, e.g. a person can have multiple identifiers (e.g. ssin, a personnel number, foreign social security number, ...).