Wed, Jan 1
FYI: I'm about to import about 15000 "new" monuments to Wikidata but won't touch the lists.
Dec 5 2019
Turns out this is also a problem within WDQS. When it comes to IDs and URIs is there a reason for encoding this type of information in the first place instead of leaving that to applications?
@AxelPettersson_WMSE thanks for the poke! Nothing for the Swedish article but for the Danish one this month on my side.
Oct 18 2019
That's one of the use cases for Wikidata. As I say Tora does not match our use cases at all.
@Salgo60 merged items in Wikidata gets sameAs statements and are redirected. Tora does not contain all of the parishes in K-samsök and would not be suitable for our Europeana use case.
- No one else has asked for additional documentation. Regarding these URIs we have only had minor support questions.
- No that is not good practice in this case, but the modeling will be updated with owl:sameAs statements(see below).
- Yes we will add Wikidata identifiers to support de-referencing by Europeana, if nothing unexpected comes up this will happen during November or early December.
- No that's an issue with Wikidata, the link is correct but Wikidata incorrectly encodes it.
@Salgo60 I will now close this issue again.
Oct 15 2019
Oct 14 2019
Sep 12 2019
Sep 9 2019
Sep 5 2019
@AxelPettersson_WMSE if there is any public documentation of the Wikidata workshop co-hosted with us and Europeana it would be nice to have a link in there.
Aug 28 2019
@Abbe98 The fact that you can neither see nor search using the old ids means that the WLM workflow is broken for anyone using new Fornsök. Do you know what the plans are around this, alternatively could you put us in touch with someone who might?
We are very close to redirect the links(ETA late September), the in October all new Fornminne data will be available in K-samsök/Wikidata.
Aug 24 2019
By default it's not possible to navigate to non text-input elements in Safari. Such a behavior can be enabled under Preferences->Advanced.
@Ciencia_Al_Poder yes, I'm thinking I could just change the default value of MediaWiki:Accesskey-ca-nstab-project...
Switching the default access key is trivial, but the old one wouldn't work. Is this okay?
Aug 22 2019
Closing this as the hackathon is over and all relevant links seems to be present here.
Aug 14 2019
So was thinking about moving the georeference data from Wikimaps Warper to Commons or Wikidata a few years back the main options were:
Jul 11 2019
@Salgo60 Phabricator is not a place for your personal opinion nor a place for your feedback to a government agency. You know from the ongoing discussion on this subject that there is no consensus on this subject in your favor. Please do not try to run people over by moving the discussion here.
Jul 9 2019
Dropping this resource here:
Jul 8 2019
This seems to be fixed.
Jul 4 2019
As we now have a data field "Visible above ground" I would like to remove all items where this value is set to false, feels like a start and is doable already this year.
Jun 10 2019
@Abbe98 please do it I feel SMVK looks having a lot of data plus also some good structures in SMVK
"SMVK-EM" is SMVK Etnografiska, "name" referrers to their person authorities and "1070548" is an ID.
@Salgo60 I have a bot for this, (Carlottas data can be accessed from SOCH and references SOCH URIs).
Jun 6 2019
@Salgo60 there is a SOCH REST instance on tool labs for use on Wikimedia projects if you would like to implement something like this.
May 27 2019
I'm fully aware of what ShEx is and how it's used.
May 26 2019
What has this to do with ShEx?
May 25 2019
What do you mean by this? The RAÄ parish data(SOCH(SOCH does however use ShEx for other data)) has no need for ShEx for because the data is static and can only be edited after review by "experts" I think the same is true for Riksarkivets parish data.
Does the frontend need to URL encode external IDs? If they are meant to be resolvable there should be no need to do so in the first place right?
May 6 2019
Apr 12 2019
@Salgo60 it does contain that information there is even an API endpoint: http://www.kulturarvsdata.se/ksamsok/api?method=getServiceOrganization&value=all&x-api=test
Apr 1 2019
What are you trying to show with your last comment? It works as expected. The accept header is ignored in the first case because you have said you want HTML in the URL and in your second example you get 404 because the URI does not exist...
Mar 10 2019
What is this issue about @Salgo60? "objectid" does not exist in the new Fornsök and the old links will be redirected when the old instance is retired. RAA Nummer is just a part of the session URL similar to "tab" because RAA Nummer is not unique.
Kulturarvsdata kommer automatiskt att peka rätt när den gamla tjänsten är ner släckt. BBR exemplet beror på att objektet i fråga inte har skördats till Kulturarvsdata.
Feb 27 2019
Feb 25 2019
I do still not see the problem you can do Federated SPARQL without the endpoint being CC0.
Feb 23 2019
@Salgo60 what are you trying to do here?
No such public endpoint exists.
Feb 5 2019
This could be a lot of work as it would likely include migrating WLM to our new monuments database/service, but it would be very valuable and if we can define actual tasks before the summer holidays we could from our side set of time(meaning my time when everyone is on vacation).
Jan 26 2019
Okej ni får gärna sluta sprida ting som att det skulle komma nya sockenkoder innan ni vet.
Jan 25 2019
Eventuellt lägger de till en ny typ av id men våra kära sockenkoder kommer nog inte att försvinna. LM brukar informera andra myndigheter och användare flera månader innan de gör större ändringar så vi behöver inte stressa upp oss.
@Salgo60 vem har sagt att LM kommer med nya sockenkoder? Du hävdar det här i rubriken och på sociala medier men i mailet ovan skriver LM bara att de tar fram en ny databas... Har du någon källa på att nya sockenkoder skulle vara påväg?
Jan 24 2019
I'm very aware of the fact that Captions isn't ideal for alt texts, but it's better then only having the file name or no alt text at all.
Jan 20 2019
Jan 11 2019
Nov 30 2018
@Ottomata I see, I think the current SDC Captions implementations should behave very much as Labels on Wikidata. I'm currently not able to edit captions on beta. But one should soonish be able to do so at any file page:
(random file page, see the captions section): https://commons.wikimedia.beta.wmflabs.org/wiki/File:Hermann_von_Wedigh_III_(died_1560)_MET_DP164836.jpg
Nov 29 2018
Nov 16 2018
Jun 12 2018
@Susannaanas I totally missed that I was mentioned here.
Jun 9 2018
May 20 2018
May 19 2018
May 13 2018
May 12 2018
For me the example behaves as expected (maybe the zoom is a bit off):
May 11 2018
May 3 2018
May 1 2018
@Yurik not successfully, but the regex itself should match single characters.
@Yurik this issue is resolved right? The RegEx now present in Sources.sourceIdReStr seams to handle one character ids fine.