Property talk:P1260

From Wikidata
Jump to navigation Jump to search

Documentation

Swedish Open Cultural Heritage URI
identifier
DescriptionSwedish National Heritage Board (Q631844) has set up a webservice for the cultural monuments, protected buildings and items that are connected to a number of museums in Sweden.
RepresentsFornminnesregistret (Q10498015), Swedish Open Cultural Heritage (Q7654799)
Data typeExternal identifier
Template parameterex: sv:Mall:RAÄ-nummer and commons:Template:Fornminne
Domaincultural heritages in Sweden (note: this should be moved to the property statements)
ExampleHidinge church (Q2892790)raa/bbr/21300000003265 (RDF)
Uppland Runic Inscription 932 (Q7899135)raa/fmi/10028200010001 (RDF)
no label (Q10577192)raa/bbra/21320000019150 (RDF)
no label (Q10577192)raa/bbrb/21420000014623 (RDF)
no label (Q19931129)shm/art/940920F11 (RDF)
Möjbro Runestone (Q1360628)shm/inventory/24203 (RDF)
Kylver Stone (Q1795104)shm/object/267753 (RDF)
no label (Q19758488)GSM/objekt/20269 (RDF)
Carl Hårleman (Q1038985)LSH/agents/14474 (RDF)
no label (Q19931017)nomu/object/NM0042820 (RDF)
Formatter URLhttp://kulturarvsdata.se/$1
Related to countryFlag of Sweden.svg Sweden (Q34) (See 60 others)
Lists
Proposal discussionProposal discussion
Current uses159,138
Search for values
[create] Create a translatable help page (preferably in English) for this property to be included here
Distinct values: this property likely contains a value that is different from all other items. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P1260#Unique value, SPARQL (every item), SPARQL (by value), SPARQL (new)
Scope is as main value (Q54828448): the property must be used by specified way only (Help)
List of this constraint violations: Database reports/Constraint violations/P1260#scope, hourly updated report, SPARQL, SPARQL (new)

Format constraint for detecting syntax errors; allows both machine-readable and human-readable URLs (with suffix '/html'). Format constraint for machine-readable URLs is preferred, see this discussion, further down.

Format constraint to explicitly track items using the human-readable URL key:

Pictogram voting comment.svg Missing qualifier for "raa/fmi/" values
Values starting with "raa/fmi/" should always have RAÄ number (P1262) as a qualifier. (Help)
Violations query: SELECT ?item WHERE { ?item p:P1260 ?statement . ?statement ps:P1260 ?val . FILTER (STRSTARTS(?val, 'raa/fmi/')) . FILTER NOT EXISTS { ?statement pq:P1262 ?x } }
List of this constraint violations: Database reports/Complex constraint violations/P1260#Missing qualifier for "raa/fmi/" values


Institutions using Kulturarvsdata[edit]

This is list of institutions using Kulturarvsdata with their identifiers and an incomplete list of identifiers used for sub-collections.

More, in alphabetical order:

  • ablm
  • ajtte
  • arme
  • bhm
  • dfh
  • enk
  • fmb
  • gfm
  • gnm
  • hem
  • heo
  • jfl
  • jm
  • kbg
  • klvm
  • lsh
  • mili
  • mm
  • nomu
  • pm
  • rsms
  • shfa
  • sk
  • sm
  • smha
  • smm-mm
  • smm-sm
  • smm-vm
  • smvk-em
  • smvk-mm
  • smvk-om
  • smvk-vkm
  • socken
  • tekm
  • tes
  • upmu
  • vax
  • vbg
  • vm
  • wws

Many of these are mapped at commons:Category:External link templates using Kulturarvsdata and w:sv:Kategori:Externa länkmallar via K-samsök. /André Costa (WMSE) (talk) 07:40, 4 May 2015 (UTC)

@André Costa (WMSE): Could we for raa also add bbrp? That would make it possible to match the architects that Swedish National Heritage Board (Q631844) covers. Example (json-ld). Ainali (talk) 09:35, 20 December 2016 (UTC)
OK by me. /Lokal Profil (talk) 15:16, 20 December 2016 (UTC)
Ok, I'll try to add it. Ainali (talk) 14:09, 4 January 2017 (UTC)

/html/ ending[edit]

There are two main ways of giving these identifiers.

The first is a redirect to the human readable webbpage ([1] for the first example). The second gets you to the official entity in the database (rdf). I would definitely recommend using the latter for wikidata where the linked data interface makes more sense. If so the description (in Swedish) should probably also be changed and we should go through existing identifiers and change these. /André Costa (WMSE) (talk) 07:55, 4 May 2015 (UTC)

I had a similair discussion about Riksdagen person-id (P1214) some days ago. This one is more difficult to change, since the difference is in the middle of the code. -- Innocent bystander (talk) 15:13, 4 May 2015 (UTC)
I changed the description to remove the /html/ ending. Do we know if there are any plans to add support for additional $ parameters in URL-like strings? Some properties, like P1413 (P1413), will not work without it. Väsk (talk) 16:16, 4 May 2015 (UTC)
Could we format a Template:Constraint:Format to discover statements that include /html/? I don't know how to make a RegExp for this, but something like 3-7 letters, forward slash, 3-10 letters, forward slash, 1-14 numerals should discover both unnecessary htmls and numbers without prefixes. Väsk (talk) 16:41, 4 May 2015 (UTC)
A second thought: It's easier for a bot or a template to remove a few letters like "/html" than adding them in the correct position. In C# I just have to add a line like t = t.Replace("/html", ""). Adding "/html" to get a human-readable version is more tricky! -- Innocent bystander (talk) 08:51, 5 May 2015 (UTC)
@Innocent bystander: While it is indeed easier to make human readable links using the /html/ style it should be noted that this is in fact not part of the actual id.included in the actual id. So the choice would be weather to use something which is easier for allowing Wikipedia to make links or something which is correct (and therefore more usable everywhere else)
@Väsk: I'm not sure the regex is that simple. If I remember correctly from the templates (linked above) there is no guarantee that the id is purely numeric or that there aren't more subparts of the prefix. /André Costa (WMSE) (talk) 14:49, 5 May 2015 (UTC)
I did not talk about how easy it is to write the id here at Wikidata. I guess that mainly will be done by bot anyway. I talked about how easy it would be to design templates to change from machine-readable to man-readable compared with the other direction.
I think it could be worth to try to add such a sulution. The regex for Rundata (P1261) looks awful, but it looks like it works.
I guess there are jokers who allow both digits and a-z-letters. That there is a violation of a constraints, does not make it automaticly wrong. -- Innocent bystander (talk) 06:19, 6 May 2015 (UTC)
Sorry. I didn't mean easier for Wikidata but (like you) easier for (human-readable) links, through templates. But the cost of making that easier would be that we have identifiers that are not actually correct (since /html/ is not part of the id. /André Costa (WMSE) (talk) 14:25, 11 May 2015 (UTC)
A temporary solution could be to use Kringla.nu in the URL formatter instead ([2][3]). A link to the original database would be preferable, as the data in Kulturarvsdata is incomplete and some of the context gets lost, but Kringla.nu does present the data in human-readable form with some additional features and a (tiny) link to the originating database. Väsk (talk) 15:27, 11 May 2015 (UTC)

Commented-out version of the format constraint comprising "/html" suffix to produce human-readable URLs

Constraint:Format|pattern=(raa/(bbr(|a|b)|fmi)/html/\d{14}|shm/art/html/9\d{5}F(1\d|[1-9])|shm/inventory/html/[1-9]\d{0,4}|shm/object/html/[1-9]\d{0,6}|GSM/objekt/html/[1-9]\d{0,4}|LSH/agents/html/[1-9]\d{0,4}|nomu/object/html/NM\d{7})

-- LaddΩ chat ;) 14:07, 19 January 2016 (UTC)

@Tore_Danielsson, Väsk, André Costa (WMSE), Innocent bystander, Ainali: any news/update/change in status/thoughts on using kulurarvsdata and formatter URL that is human readable?

I feel kulturarvsdata is the "only" property in Wikidata that not goes to a human readable page which feels odd

Feels like a mess that if you should check the data in Wikidata then you need to understand how to change the URL to a human readable form?

Another example that I found that feels not user friendly and wrong because lack of human readable form is to have this URL in reference URL (P854) Example....

If linked data and museums and registers should be connected and used we need to make it easy to use/access step 1 is make it human readable..... - Salgo60 (talk) 12:00, 12 November 2017 (UTC)

@Salgo60: There is now more than one property for this and, to be honest, I have no ------- clues what these other properties are designed for. -- Innocent bystander (talk) 07:30, 13 November 2017 (UTC)

common.js[edit]

importScript('User:Salgo60/kulturarvsdata.js'); // see script from Abbe98 https://github.com/Abbe98/human-readable-kulturarvsdata

@Yger: add the above line in your common.js It is a small script by Abbe98 (talkcontribslogs) that change the URL for Swedish Open Cultural Heritage URI (P1260) to the human readable version compare my User:Salgo60/common.js - Salgo60 (talk) 20:00, 11 November 2018 (UTC)

Dublicate URIs in examples?[edit]

I see that some of the examples have duplicated claims, where both the raw URI and the HTML one is used. Is that relay a good solution? Shouldn't Wikidata always prefer the raw RDF one? When does it make sense to have both the raw URI and the HTML one? --Abbe98 (talk) 10:47, 13 September 2016 (UTC)

@Abbe98, Innocent bystander: This come back to the section on /html/ ending above. That said I would still say both duplicates and the html version should be avoided. Programmatically it should be fairly easy to do a right handed partition on "/" and inject the "/html/" string (something like the following in python parts = value.rpartition('/'); html_version = parts[1] + '/html/' + parts[2]). That solves the problem of handling these id's in Wikipedia infoboxes etc., what we loose is the ability to click on the id in the Wikidata UI and end up in the html page since the UI doesn't allow that type of string manipulation and kulturarvsdata doesn't apply content negotiation to the "main" url @Ainali.
Since there currently doesn't seem to be any values containing html though now would be a good time to disallow the html version if that is what we want to do. /André Costa (WMSE) (talk) 10:28, 27 January 2017 (UTC)
I got a user-script for the Wikidata UI issue and the fact that there is no instances of URIs pointing to the HTML version is my fault too... pip install ksamsok is a thing too(whenever you need to deal with SOCH URIs). So I definitively thinks that html(jsonld/xml etc.) should be disallowed. --Abbe98 (talk) 15:58, 27 January 2017 (UTC)

FYI: An RAÄ internal CR has been created for supporting en:content negotiation by Abbe98 (talkcontribslogs) is my understanding - Salgo60 (talk) 07:14, 18 January 2019 (UTC)

mixing subjects[edit]

@André Costa (WMSE), Ainali, Abbe98: et al! It looks like you intend to start a project where you will massimport data from fmis? That is fair with me, I love to work with that! But you have to consider one thing! The article sv:Björkå is about a "småort" and two "gravfält". Multiple-subject WP-articles is one thing, but multiple-subject items is a "ursäkta franskan: en finne i arslet". Is it the "småort" or "Holms gravfält" who has a population of 67 persons. Is it the småort or gravfält who "has part:burial mound quantity:27". Is it the graves or the settlement who has "shape:oval with a pit at the top". -- Innocent bystander (talk) 14:20, 29 January 2017 (UTC)

After reading Help:Handling sitelinks overlapping multiple items I think that Wikidata item should be rebuilt to have has part (P527) with three new items, one for the "småort" and one for each "gravfält". The same could be done for all other "bundled" articles on svwiki. Some check for items with instance of (P31) minor locality (Q14839548) and also Swedish Open Cultural Heritage URI (P1260) should be done before any import to help reveal such items. Ainali (talk) 20:11, 29 January 2017 (UTC)
@Innocent bystander, Alicia Fagerving (WMSE), Ainali, Abbe98: The plan is to import the data in the WLM database to Wikidata. FMIS is probably not the first one, but likely one of the first. I agree with Ainali that these should definitely be three separate items with the item connecting to the Wikipedia article containing a has part (P527) (only?). For importing the WLM data I think the main issue will be to detect any false positives. E.g Björkå (Q2368410) contains Swedish minor urban area code (P776) so it cannot be a FMIS object (even if it contains a RAÄ number (P1262)). Another warning signal could be that w:sv:Lista över fornlämningar i Sollefteå kommun#Överlännäs links to w:sv:Björkå via the redirect w:sv:Björkå gravfält. I think a good first start would be to ensure RAÄ number (P1262) has some sensible constraints for instance of (P31). /André Costa (WMSE) (talk) 10:11, 30 January 2017 (UTC)
@Innocent bystander, André Costa (WMSE), Ainali, Abbe98: Examples like this make me more and more in favor of just mass-removing all claims that use RAÄ number (P1262) right before starting the import. That way, new items for "Holms gravfält" and "Björkå gravfält" will be created from scratch, without overlapping with Björkå (Q2368410). Not sure about the has part (P527) -- in this case, it's about an object located in a village/town, and I haven't really seen this property used like that. And if an item in the Wikipedia list links to a redirect or to an article section (indicating that an article about this particular thing does not exist), the link could be ignored. --Alicia Fagerving (WMSE) (talk) 11:13, 30 January 2017 (UTC)
sv:Hemsjö, Alingsås kommun is an example of an article on svwiki with multiple subjects, and with a template with WD-support to extract data from three different items. (1. The item about the pair, 2. The item abut the "tätort", 3. The item about the "småort".)
No template is today adapted to the situation in sv:Björkå. One problem here is that this template-solution (based on the Geobox) is very expensive in terms of how much resources the templates and modules needs to render the page. -- Innocent bystander (talk) 11:52, 30 January 2017 (UTC)
@Alicia Fagerving (WMSE): Of the around 1100 items with RAÄ number (P1262) only around 100-200 seem to be wrong. I can clean that up manually this week so no need for mass removal. Ainali (talk) 12:38, 30 January 2017 (UTC)
@Ainali: True, I was thinking in the context of Property_talk:P1262#Qualifier_to_Cultural_heritage_database_in_Sweden_.28P1260.29.3F -- that is, removing the RAÄ number as a standalone statement and moving it to qualifier. --Alicia Fagerving (WMSE) (talk) 12:54, 30 January 2017 (UTC)
@Alicia Fagerving (WMSE): Ah, I had missed the recent development in that discussion, but it makes perfect sense. And then your proposal about botfixing standalone statements is something I support. Ainali (talk) 09:12, 31 January 2017 (UTC)
@Alicia Fagerving (WMSE), Ainali, Innocent bystander: For the Wikidata items corresponding to Wikipedia articles on multiple subjects the needed action would be threefold: Break out the FMIS item into a separate item, break out the småort info into a separate item, replace the contents of the Wikipedia-article-item with two has part (P527) claims and some suitable instance of (P31) (something more specific than Q17519152 ideally). A fixing of these 100-200 objects would be needed whether or not we then change to P1260 as a qualifier only.
I'm not sure the Infobox issue is a blocker here. sv:Björkå already uses three infoboxes to deal with the fact that it is actually supposed to be multiple articles. We shouldn't expect templates, or the associated Lua to be the solution for that. A potential work-around for this case would be if the templates could accept a parameter which was "show me as if I was <this> wikidata id". /André Costa (WMSE) (talk) 10:14, 6 February 2017 (UTC)
RE: "show me as if I was <this> wikidata id" is fully possible to implement! I do not have the time to change the Ortsfakta WD-template now, but it is rather straightforward to fix. -- Innocent bystander (talk) 09:04, 7 February 2017 (UTC)
I made a stab at Björkå. Björkå (Q2368410) is now split up and has part (P527): Björkå gravfält (Q28731191), Q28731194 and Q28731198. Is that a way to go? Ainali (talk) 09:27, 8 February 2017 (UTC)
In my book the above separation of Björkå (Q2368410) looks to be right. =) /André Costa (WMSE) (talk) 14:18, 8 February 2017 (UTC)

"Good patterns"[edit]

I think it would be good when we map Swedish Open Cultural Heritage URI (P1260) to RAÄ that we also use mapping relation type (P4390) together with

so the WD reader understands if we use the same concept that RAÄ use or if its nearly the same - Salgo60 (talk) 15:33, 27 August 2018 (UTC)

Suggested changes to property[edit]

The Kulturarvsdata property has primarily been used for buildings and heritage sites, however outside of Wikidata-land its used for a lot of different types of records, mainly ones representing an item found in archives. This is currently not reflected in the constraints of this property.

Suggested changes to constrains:

  • Removal of item requires statement constraint heritage designation
  • Removal of item requires statement constraint country Sweden
  • Removal of item requires statement constraint coordinate location
  • Removal of item requires statement constraint located in the administrative territorial entity
  • Removal of distinct values constraint


The second subject is the format of the id, the examples and Regex suggest that this property supports values like <inst>/<serv>/<id> as well as <inst>/<serv>/html/<id>. Although the later is supported and many simliar formats as well, there is not a unified commitment at the SNHB to provide longterm support for these URLs. URLs of this type has been changed to the URI by bots for at least two years. The format Regex also defined the allowed service and institution values, however most of the used values are missing from the Regex and there are over 60 values for institutions and over 120 for services.

Suggested changes to format Regex:

  • Simplified format Regex .+\/.+\/.+
  • Removal of all HTML URL examples.


Abbe98 (talk) 13:28, 10 December 2018 (UTC)

Notifying @Lokal Profil, Alicia Fagerving (WMSE): who have been heavy users of this property.