Wikidata

Wikidata:Property proposal/Europeana Entity

< Wikidata:Property proposal

Europeana Entity

edit

Originally proposed at Wikidata:Property proposal/Authority control

DescriptionEuropeana code entities for persons, places, topics
Representshuman (Q5), subjects, places
Data typeExternal identifier
Domainitem
Allowed values(place|agent|concept|organisation)/.*
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)[reply]

Discussion

edit
  Support --Kolja21 (talk) 15:33, 1 December 2019 (UTC)[reply]
  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)[reply]
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)[reply]
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)[reply]

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 P727 (P727), where 80% of all links are broken. Husky (talk) 12:13, 4 December 2019 (UTC)[reply]
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)[reply]
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)[reply]
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
Thanks for fast feedback. I sent an email if we could have an online chat about good and bad patterns when designing WD properties like beeing stable and having content negotiation and not just RDF... as we now passed 7000 properties (see tweet) in Wikidata I feel its good if we try to make it as easy as possible for the reader/user to understand the relation between Wikidata and the Europeana property. "Problems" I have seen is places that often are not welldefined - Salgo60 (talk) 14:24, 9 December 2019 (UTC)[reply]

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)[reply]


@ديفيد عادل وهبة خليل 2, Multichill, Hmangas, Salgo60, Vladimir Alexiev, CalvinBall: @Husky, Kolja21:   Done: Europeana entity (P7704). − Pintoch (talk) 20:34, 9 December 2019 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Europeana_Entity&oldid=1093858503"