Storing National Identity Numbers, Passport Numbers etc in Schema.org

[jonathanendersby]

I realise this is perhaps not the correct place to ask this question, however the issue has been raised via the mailing list last year by someone else and was not answered, so I'm raising it here in hope there is a straight forward answer.

How does one store a national identity number in schema.org format? Given:

{
"@context": "http://schema.org/",
"@type": "Person",
"name": "Jonathan Endersby",
"givenName": "Jonathan",
"familyName": "Endersby",
"birthDate": "1980-02-20",
"gender": "Male"
}

How would I add a South African National Identity number of "8002203838229" to that entity? (that's not my real ID, don't worry).

I realise that this may have to go via a "serviceOutput", but I'm yet to find a clear example of that.

Thank you in advance.
J.

[danbri]

We don't have a structure for this yet. One approach would be as explored in #1186 where we try to use properties from Wikidata within a Schema.org JSON-LD setting. The Wikidata folk have added lots and lots of these kinds of identification properties. I don't know if they have the one you're interested in, though.

Perhaps we might also extend http://schema.org/additionalProperty to be applicable on more types (like Person); this would allow you to make up your own structure that indicated a value was South African national ID...

[thadguidry]

Wikidata does not have the South African National Identity number.

+1 for extending http://schema.org/additionalProperty

Since there are a few important properties currently missing from Person like profession.

[mfhepp]

Note that my initial proposal when crafting additionalProperty to make this applicable to schema:Thing, but so many Semantic Web folks raised concern that this would be an evil extension mechanism that I had to contrain it to schema:Product.

See here and the following hundreds of emails if you want to understand the context:

https://lists.w3.org/Archives/Public/public-vocabs/2014Apr/0295.html

Martin

---

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 09 Sep 2016, at 14:54, Dan Brickley notifications@github.com wrote:

We don't have a structure for this yet. One approach would be as explored in #1186 where we try to use properties from Wikidata within a Schema.org JSON-LD setting. The Wikidata folk have added lots and lots of these kinds of identification properties. I don't know if they have the one you're interested in, though.

Perhaps we might also extend http://schema.org/additionalProperty to be applicable on more types (like Person); this would allow you to make up your own structure that indicated a value was South African national ID...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[davux]

Any news on this? I believe it is still current.

[RichardWallis]

Since this thread went quiet the identifier property was introduced in v3.2 and can be used thus:

{
"@context": "http://schema.org/",
"@type": "Person",
"name": "Jonathan Endersby",
"givenName": "Jonathan",
"familyName": "Endersby",
"birthDate": "1980-02-20",
"gender": "Male",
"identifier": {
    "@type":"PropertyValue",
   "propertyID": "South African National Identity number",
   "value":  "8002203838229"
   }
}

or:

{
"@context": "http://schema.org/",
"@type": "Person",
"name": "Jonathan Endersby",
"givenName": "Jonathan",
"familyName": "Endersby",
"birthDate": "1980-02-20",
"gender": "Male",
"identifier": {
    "@type":"PropertyValue",
   "propertyID": "http://www.wikidata.org/entity/Q22908937",
   "value":  "8002203838229"
   }
}

The Wikidata URI I used in this example is for South African identity card, which I presume (as a non-expert) is the source of said number.

[davux]

Thanks @RichardWallis, this works.

I think we can do better though, by standardising a few properties of those identifiers. For example, since it's a national ID, there is an emitting country. Then, inside a given country, there are sometimes a couple of different valid types of national documents, for example in Peru of you have Peruvian nationality you will have a DNI (documento nacional de identidad, national identity document) but if you're an authorised resident what you have is a CE (carnet de extranjería, foreigner card). So those are local types. However there are also global types such as passport. What's the name of the South-African one(s)? Last but not least, as a person you may well own several of those documents.

I believe what we need is a full-fledged Government identifier with maybe documentNumber, documentType, (with a few fixed types such as "nationalId", "passport", etc.), and a local subtype. Or maybe just try to list all existing types with a syntax such as "passport", "DNI", "CE", "SSN", etc. in one field. And then other properties such as validFromDate, validUntilDate...

Thoughts?

[RichardWallis]

A couple of thoughts come to mind.

• A Person could have an array of any number of these identifier values which would take care of the different types you reference. Using well known values for propertyID, Wikidata references for example could introduce the standardisation you are looking for.

• The main use case (not the only but the main one) for Schema.org is to provide data for sharing on the web to help in the description and discovery of things. I am struggling to see where in that use case it would be desirable to share this detailed personal information.

[davux]

I'm thinking of digital identity such as the one worked on by the Credentials and the Verifiable Claims W3C working groups. With proper ACLs, you might want to share your government document number(s) with certain entities such as a bank for example, as a verifiable claim.

[github-actions]

This issue is being tagged as Stale due to inactivity.

[davux]

I'm not willing to drop this (yet).

Maybe a good way to describe a national ID is through URNs. Something like urn:gov:<country_code>:<whatever> where <country_code> is a 2- or 3-letter country code and <whatever> is whatever the best practice in that particular country is—typically <document_type>:<document_number> but not necessarily.

One more difficult case would be passports, since those have a fixed pattern of country + passport number. Maybe for passports a specific type of URN could be used, such as urn:pport:<country_code>:<passport_number>.

One advantage of describing an ID document as a single identifier (as opposed to a compound object) is that you can use it to refer to an individual as easily as with any other identifier. In particular, you can trivially refer to individuals in Verifiable Credentials through the credentialSubject.id attribute.

I'm curious about opinions and/or existing practices on the matter.

[dr-shorthair]

I kinda like using a generic rdfs:Literal or xsd:string, and then qualify it with an rdfs:Datatype for each authority.

[WeaverStever]

There are blockchain projects working on this where the person will decide what data is disclosed.
https://cointelegraph.com/news/blockchain-digital-id-putting-people-in-control-of-their-data

Since it is generally best to model the schema after external ontologies, we might want to allow the blockchain efforts to mature a little more?

[vongohren]

Three years later and there does not exist a solution :) ?
Now with EU Wallet ID on the there has to be some good schemas for this?

[WeaverStever]

@vongohren

@RichardWallis provided a solution for this (in this thread) on Sep 1, 2017.

Considering the privacy issues, I think this topic would be better handled by an outside ontology or private firm. The person should be able to reject or allow this type of information when a query is generated.

What could be handled by schema.org is Folksonomy tagging and identities. These are identifiers that the person wants in the Knowledge Base. (also, Google seems to prefer that these wound would not be included in sameAs properties.)

[vongohren]

The main use for us is to use this with https://www.w3.org/TR/vc-data-model/.
Then you can reject requests on your own terms and accept them whenever they come.
You controll that piece of information that is issued in an issuance sequence