I fully agree with the approach to put as little semantics as possible in
the identifier. Avoid including anything that may change.

And there is a famous statement by Dan Brickley:  "you're more likely to
regret things you included, than things you omitted".


-----Mensaje original-----
De: Discussion list for Europeana Technical Developments
[mailto:[log in to unmask]] En nombre de Henk Vanstappen
Enviado el: 24 March 2015 16:21
Para: [log in to unmask]
Asunto: Re: Your advice on minting URIs for contextual entities

Hi Antoine,

I take the same vote as Lizzy for the same reasons.

As a compromise, you could follow the approach of VIAF, where Bach has a
numerical identifier (, but is presented also

And eventually it might be a good idea to refer to the VIAF uri too, of

best wishes,


Henk Vanstappen
[log in to unmask]

On 24 Mar 2015, at 15:45, Antoine Isaac wrote:

> Dear all,
> We're about to mint identifiers (URIs) for contextual entities to be used
in Europeana. This will concern concepts, agents or places to be used for
enrichment [1] and a couple of other things. The data will be adapted from
external or providers' datasets, and will eventually have to be available as
linked data on
> After internal discussions, we have to choose between two options:
> 1. A bare numerical identifier, as in
> 2. A number combined with a human-readable label, as in 
> In any case URIs would lead to machine-readable data for software clients,
while humans would be directed to pages like [2]. But human-readable labels
in identifiers would help to identify and discuss the resources more easily.
So option 2 is very tempting.
> However, option 2 is slightly harder to implement. Also, we would have to
choose one field in the data, and one language (as we do for other
communication, including this mail). Both field and language could change
from one source to the other, when we merge different datasets.
> We're curious to hear whether you have a preference! We have created a
small poll:
> Note that it is not a a majority vote. We may end up not have the resource
to implement the more complex option. Also, one could have a killer argument
for one option, that defeats all other considerations :-). You can leave
comments at the bottom of the poll page.
> Thanks a lot for the advice!
> Antoine
> [1] 
> MBj1pEx0Y/
> [2]