Wikidata:Property proposal/Europeana Entity

From Wikidata
Jump to navigation Jump to search

Europeana Entity[edit]

Return to Wikidata:Property proposal/Authority control

   Under discussion
DescriptionEuropeana entities for persons, places, topics
Representshuman (Q5), subjects, places
Data typeExternal identifier
Domainitem
Allowed valueshttp://data.europeana.eu/(place | agent | concept | organisation)/{identifier}
Example 1Anders Zorn (Q206820)agent/base/61829
Example 2Bruno Liljefors (Q730008)agent/base/73049
Example 3watercolor (Q50030)concept/base/221
Example 4oil painting (Q174705)concept/base/222
SourceEuropeana Entity API
Number of IDs in source> 400 000
Expected completenessalways incomplete (Q21873886)
Formatter URLhttp://data.europeana.eu/$1

Motivation[edit]

Europeana now supports entites for persons, places , topics (see Europeana Entity API) which means that Europeana is a good candidate to be a stable Wikidata Property see discussion d:Property_talk:P727#Europeana_entity and my task T239441

- Salgo60 (talk) 10:26, 1 December 2019 (UTC)

Discussion[edit]

Symbol support vote.svg Support --Kolja21 (talk) 15:33, 1 December 2019 (UTC)
Symbol support vote.svg Support The formatter URL should ideally use the base Europeana entity URL instead of the URL it redirects to, so that future redirects created by Europeana will still work. E.g. [1] is the Europeana Entity API URL that redirects to [2]. Using https://data.europeana.eu/entity/$1 will catch all entities and will keep on working when Europeana puts new redirects in place. It doesn't distinguish between concepts, agents or places, but this can be achieved with the correct SPARQL query to Regex select only the entities you want. CalvinBall (talk) 09:08, 2 December 2019 (UTC)
Thanks I updated using https://data.europeana.eu/entity If Europeana would like to use Wikidata for cleaning its data I guess it will be better to have separate properties and have different rules. We did that with WikiTree 2016 we started with one property WikiTree person ID (P2949) that we now have split into one for people and one for places/cemeteries..... WikiTree use WikiTree person ID (P2949) and the Wikidata constraints report and every week generate diff reports what is needed to be checked in WikiTree and now we created a new property for places/cemeteries WikiTree category or space (P7607) etc.
The problem I have seen with Places and archives / museums in Sweden is that Wikidata in Sweden has better granularity than museums and most archives i.e. they define a place with a name and a coordinate and nearly never "same as" a city/parish/mainson --> the "places" data needs more curation before they are a good member in a linked data environment. Example Anders Zorn above has Mora as birth place is that Mora (Q849874), Mora Parish (Q10588907) or Mora Municipality (Q504239). See example Uppsala University Alvin ID (P6821) they have alvin-place:287 that they call Mora were we need to guess what it match in Wikidata (I used Mora Parish (Q10588907)) see map with all matched Alvin places matched in Wikidata > 1400 places
Best would be if we set up a "standard" saying that we i.e. in Sweden use the church parish as birth/death location "same as" WIkidata or in Sweden we also have the National Archive TORA ID (P4820) that we right now connects with Wikidata see church parish map and Tora task T199794 - Salgo60 (talk) 10:15, 2 December 2019 (UTC)
  • Pictogram voting comment.svg Comment The suggested property appears to match the existing property David (talk) 11:40, 2 December 2019 (UTC)
    • yes and no in this case Europeana is trying to take care of its metadatadebt is my understanding and creates entities that are stable. Listen to presentation Europeana 2019 i.e. I think its better to have a new property as we today just have a mess in Wikidata <-> Europeana. Compare property proposal Wikidata:Property_proposal/Riksdagen_person_guid were we have a source that is stable and just change its ID to GUID i.e. we have stable identifiers in the source before and after. In Europeana I understand we have a mess and move to something stable/persistant then I feel its better to depreciate/delete the old property and create a new one see also Wikidata:Properties_for_deletion - Salgo60 (talk) 11:52, 2 December 2019 (UTC)
  • Symbol support vote.svg Support although the Europeana entities are relatively few and the majority are borrowed from other datasets. @ديفيد عادل وهبة خليل 2, Salgo60: This is different from Europeana ID (P727) because these are "contextual objects" (agents, places, subjects) not Cultural Heritage Objects, and the way these datasets are curated is very different --Vladimir Alexiev (talk) 12:14, 2 December 2019 (UTC)
borrowed or not a person is a person and I guess if Europeana should add value it must have better data quality and better linked data. I did a small test of the data quality in Europeana on Anders Zorn (good unique name;-) ):
see more tests done T239441 and it looks like Wikidata <-> Europeana could help each other and as Wikidata has more than 6500 properties and is CC0 it maybe can help Europeana to clean its data see list
- Salgo60 (talk) 12:36, 2 December 2019 (UTC)
  • Symbol support vote.svg Support This concept matches a lot better with the data model on Wikidata than Europeana ID (P727). I would be in favour of actually deprecating that old property, or at least deleting all the statements that use it, once this gets accepted. Most of the links using Europeana ID (P727) are broken anyway. Husky (talk) 16:22, 2 December 2019 (UTC)
  • Symbol support vote.svg Support yes, and I see the URI's have been fixed. Multichill (talk) 20:24, 2 December 2019 (UTC)

Feedback from Europeana Foundation Hmangas (talk) 13:01, 3 December 2019 (UTC)[edit]

  • We also support the option to have a single property for all kinds of entities and differentiate from the existing Europeana ID which is meant to reflect cultural heritage objects. However, the pattern for the URI is not quite following the URI that we have designed, since:
    • The entities do not share a base URI beyond Europeana's data namespace (data.europeana.eu) which is also shared by Europeana items as http://data.europeana.eu/item/*
    • The protocol part of the URI is HTTP and not HTTPs
  • The pattern is instead as follows: http://data.europeana.eu/(place | agent | concept | organisation)/{identifier}
  • This would result on the URI pattern: http://data.europeana.eu/$1 (which is the same for the Europeana ID) which will then match the examples in the property definition (e.g. concept/base/221). Btw, at some point we will remove the "base" from our URIs as it serves no purpose, but that can easily be done without changing the property definition.
I'm a bit worried about the fact that the `base` part of the URI's will be removed at some point in the future. What will happen to all the existing properties then? Will the /base/ urls redirect to the versions without /base/? We don't want a situation similar to the one with Europeana ID (P727), where 80% of all links are broken. Husky (talk) 12:13, 4 December 2019 (UTC)
I agree we need to get a date from Europeana when they support the new persistent URI ping: @Hmangas:. Start populating Wikidata with something that is not persistent is an antipattern see W3 URI Policy for Persistence - Salgo60 (talk) 14:29, 4 December 2019 (UTC)
Of course we will not do this lightly, we will first put in place a redirection on our site and then propagate the change. We will preserve this for a period of no less than 1 year after the propagation is made. 194.171.184.20 14:48, 4 December 2019 (UTC)
A note that the Europeana Entity URIs are formal URIs in the Linked Data sense, so it would be better to replace the formater URL with the formater URI property

Europeana Fashion[edit]

Anyone who can explain the future of Europeana Fashion Vocabulary ID (P3832) and Europeana Fashion creator ID (P3482)? Feels they should be part of the new Europeana Entity concept

- Salgo60 (talk) 19:50, 2 December 2019 (UTC)