Wikidata:Property proposal/KRNLK
Jump to navigation
Jump to search
National Library of Korea Identifier (KRNLK)[edit]
Originally proposed at Wikidata:Property proposal/Authority control
| Description | Identifier for a person in the database of the National Library of Korea |
|---|---|
| Data type | External identifier |
| Example | Jonathan Crary (Q6272840) → KAC201501465 |
| Source | VIAF of Jonathan Crary → KRNLK page on VIAF |
| Planned use | In person's items, like above |
- Motivation
Hello,
By filling up the authority properties in Jonathan Crary (Q6272840) based on his VIAF page, I discovered this authority identifier that I believe doesn't exist in wikidata.
I think it might be useful to have it like the others. Sorry, if I didn't fill correctly this form: I am not used to it.
Regards, Daehan (talk) 12:49, 25 November 2017 (UTC)
- Discussion
Support. We can use http://viaf.org/processed/KRNLK|$1as a formatter URL, so long as the "|" doesn't break anything (as it does if used in the above template). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:29, 25 November 2017 (UTC)
- I'd rather link to NLK LOD with the following formatter url:
http://lod.nl.go.kr/resource/$1e.g Jonathan Crary (Q6272840) → KAC201501465. Is there a precedent for the creation of additional properties that link to VIAF? After the VIAF ID (P214) has been added to an item the subsequent use of another property that also links to VIAF would be unnecessary and it doesn't seem like an entirely satisfactory solution. Sic19 (talk) 22:28, 4 December 2017 (UTC)
- I'd rather link to NLK LOD with the following formatter url:
- Support The property has my support presuming that we reach an agreement regarding the formatter url. Sic19 (talk) 22:28, 4 December 2017 (UTC)
- Not ready, given that no agreement about the formatter url has been reached. ChristianKl (✉) 10:58, 7 December 2017 (UTC)
Comment I agree the lod.nl.go.kr site would be the best formatter URL here. However, since this is a Linked Open Data URL, I think this is what exact match (P2888) was designed for, so I'm doubtful we need a new property for this. ArthurPSmith (talk) 19:27, 7 December 2017 (UTC)
- Thanks, I think that exact match (P2888) is sufficient for linking to the National Library of Korea authority data. Sic19 (talk) 11:57, 9 December 2017 (UTC)
- Support SERutherford (talk) 19:20, 1 January 2018 (UTC)
- Support Danrok (talk) 00:53, 5 January 2018 (UTC)
Oppose, let's use exact match (P2888) as suggested above − Pintoch (talk) 00:51, 29 January 2018 (UTC)
- @Pintoch: I don't quite get it. What does this identifier have/not have that makes it use P2888?
--- Jura 09:45, 22 March 2018 (UTC)- @Jura1: it is already available in linked open data, so we should not need to create a special property to link to it: the interoperability is already provided on their side. Their data is already exported in RDF, and these URIs can be used not just to view the contents of the records, but also to refer to the object in RDF (you can see that via the links on the side, to the various RDF serialization formats). They have a SPARQL endpoint, which could probably be connected to the wikidata query service via federation (if it's not done already?) − Pintoch (talk) 09:57, 22 March 2018 (UTC)
- So all identifiers that allow this should be using P2888? This is would be something new, unheard of. I don't think we already include this one in P2888.
--- Jura 10:00, 22 March 2018 (UTC)- Not new at all - that was the basis of the discussion around schema.org long ago, why we don't have a special property for that. Custom properties aren't always the right solution. ArthurPSmith (talk) 17:16, 22 March 2018 (UTC)
- that property is already using it, but this one would be new. What is so different about this one compared to other VIAF?
--- Jura 17:19, 22 March 2018 (UTC)
- that property is already using it, but this one would be new. What is so different about this one compared to other VIAF?
- Not new at all - that was the basis of the discussion around schema.org long ago, why we don't have a special property for that. Custom properties aren't always the right solution. ArthurPSmith (talk) 17:16, 22 March 2018 (UTC)
- So all identifiers that allow this should be using P2888? This is would be something new, unheard of. I don't think we already include this one in P2888.
- @Jura1: it is already available in linked open data, so we should not need to create a special property to link to it: the interoperability is already provided on their side. Their data is already exported in RDF, and these URIs can be used not just to view the contents of the records, but also to refer to the object in RDF (you can see that via the links on the side, to the various RDF serialization formats). They have a SPARQL endpoint, which could probably be connected to the wikidata query service via federation (if it's not done already?) − Pintoch (talk) 09:57, 22 March 2018 (UTC)
- Comment Wasn't external identifier datatype created to provide interoperability on our side?
--- Jura 09:07, 3 April 2018 (UTC)
- @Pintoch: I don't quite get it. What does this identifier have/not have that makes it use P2888?
- Comment The problem with exact match (P2888) is that currently its value limitation is unclear, thus it would also be possible Covenant Christian Coalition (Q24896411)exact match (P2888)China Compulsory Certificate (Q1073253) (are you really beliving with that?) --Liuxinyu970226 (talk) 00:10, 1 April 2018 (UTC)
- @Liuxinyu970226: sorry I don't understand your example at all - can you elaborate? exact match (P2888) has a URL datatype so you cannot use it in this way. What do you mean by "value limitation"? What interpretation of the semantics of exact match (P2888) would allow your example? − Pintoch (talk) 07:56, 3 April 2018 (UTC)
@Daehan, Pigsonthewing, Sic19, ChristianKl, ArthurPSmith:@SERutherford, Danrok, Pintoch, Jura1, Liuxinyu970226: 
Done Micru (talk) 18:32, 10 April 2018 (UTC)