Wikidata:Property proposal/ISOF place

ISOF Place edit

Originally proposed at Wikidata:Property proposal/Place

   Not done
DescriptionPlace name register of Swedish places created by ISOF
RepresentsSwedish Institute for Language and Folklore (Q7654721)
Data typeExternal identifier
Domainsocken (Q1523821)
Example 1Söderala parish (Q10688474)parish-id=176
Example 2Gävleborg County (Q103699)county-id=20
Example 3Algutsrum Hundred (Q4724394)district-id=154
Example 4Sala Silver Mine (Q3314828)place-names/1771147 also same as Hembygdsportalen ID (P6192)171278
SourceWebrest API PlaceNameService see also Notebook
Planned useWikipedia articles and connect with other external identifiers
Number of IDs in source2 million objects
Expected completenessas many as possible at least as many asSwedish place name register SOFI (P5536)
Formatter URLhttps://placename.isof.se/PlaceNamePublic/place-names?$1 this project is in Beta so its not stable yet so this will be updated
See alsoSwedish place name register SOFI (P5536) old version

Motivation edit

A new application is developed and they will change id. We have the old application in Swedish place name register SOFI (P5536) but as they will run both applications in parallell and that they change the structure we propose to create a new property for the new application: Hopefully this new application can be an authority for Swedish places - Salgo60 (talk) 11:59, 11 November 2020 (UTC)[reply]

Update no futher activity is planned with ISOF from my side so I guess this is not needed... - Salgo60 (talk) 08:54, 20 April 2021 (UTC)[reply]

Discussion edit

  Comment I believe we should have a property for the new ISOF places, it looks like they can give a lot of background information. However, the ID's in the examples seem conflated with what a URL formatter should do, and when looking at the ID's in their system, they are not named like that at all. So this would be a new ID constructed by us rather than any official ISOF ID. However, in your notebook it seems to be a so far unnamed column with a unique identifier. If that would become something referenceable then I would like us to adjust the proposal and move forward, but as it is right now I would oppose and instead suggest to split this into separate properties for each of the types (parish, county, district, place) so that we could use their native ID. Ainali (talk) 16:26, 11 November 2020 (UTC)[reply]

Ainali What we suggest above is an unique pattern I will double check that with the developer but I feel splitting the property will add no added value. E.g. property Uppsala University Alvin ID (P6821) see also T225522 has nearly the same pattern that I feel makes sense... e.h.
I hope Alvin move direction also support "things" like Alvin-taxon:nnnn, Alvin-parish, Alvin-museum.....
What I miss at ISOF is that they dont display this key in the user interface as Alvin does.... my understanding is that ISOF has plans for an identifier fields but we have seen no specifications for that object... changing value is no major problem as we did that with Hembygdsportalen ID (P6192) they changed last year plattform and did the bad decision to also change all "Persistent" Identifiers
- Salgo60 (talk) 20:34, 11 November 2020 (UTC)[reply]
Hmm. This is not how that property was presented when approved, and it has deviated from that approval without any discussion on the discussion page. Perhaps that one need a cleanup as well? Ainali (talk) 20:56, 11 November 2020 (UTC)[reply]
@Ainali: do what you want... I feel the problem is the lack of dialogue WD <-> Alvin I have since 2019 been trying to get a meeting with Alvin people see T226099 and also I hope to get some commitments from them. I have met Per Cullhed twice at other events and spoken with wadskog 20200914 on the phone but we havnt been sitting down and share future plans and issues. I feel Alvin dont have a linked data vision and they have no interest in better connect with Wikidata/Wikipedia. I am also interested in to get them better support typed species see T236310 - Salgo60 (talk) 21:47, 13 November 2020 (UTC)[reply]
Another approach that we could move forward with immediately would be to switch this to not be of the type external-id (since this is several different external-id's) and instead use URL, which seems to be what this really is. Ainali (talk) 21:16, 11 November 2020 (UTC)[reply]
URLs is a bad pattern I think we should try follow the DRY pattern and have in the argument something connected to a "thing" and things that can differ in the formatting URL... we have seen before problems with "moving" applications at SOFI that never was fixed see T200979. Below I do a draft of a checklist what we(Wikidata) want from an external identifier - Salgo60 (talk) 21:47, 13 November 2020 (UTC)[reply]