WOW. Thanks a lot for so much relevant feedback, and so quickly! We are very lucky to have such a wonderful community.
So now option 1 is clearly ahead...
I'm putting in the PS a reaction to some of your individual points.
- if we get the chance to get VIAF links in any data, be sure we will keep them preciously.
- using hexadecimal identifiers instead of purely numerical ones is very tempting!
- allowing several identifiers is still an option. But it's less simple that it seems...
It is indeed possible to point a client to http://data.europeana.eu/agent/12345
when it client requested http://data.europeana.eu/agent/12345_johannes_sebastian_bach
or http://data.europeana.eu/agent/12345/johannes_sebastian_bach, http://data.europeana.eu/agent/12345#anything, etc
The problem (just extending on what Nuno said) is that data consumers will probably expect data that involves the precise URI they asked about in the first place.
Concretely, if an agent sends a request for http://data.europeana.eu/agent/12345_johannes_sebastian_bach
then it would expect statements where the subject is http://data.europeana.eu/agent/12345_johannes_sebastian_bach
not statements where the subject http://data.europeana.eu/agent/12345
So they could just belive that the data they got just doesn't describe what they want!
Solutions exist, but it will be hard to avoid mentioning the URI-with-label in the data in addition to the URI-without-label. If just for adding a sameAs statement to glue the two identifiers together:
http://data.europeana.eu/agent/12345_johannes_sebastian_bach owl:sameAs http://data.europeana.eu/agent/12345 .
And as Nuno said, requiring data consumers to interpret the sameAs statement could raise issues.
An alternative is to introduce URI-with-label next to URI-without-label, *but only for human consumption*. I.e, we should make clear that machines should use the URI-without-label.
But this could be hard to enforce across the board!