Thanks, Antoine, for flagging this.
Beginning with the second (less important) one: That's just a straight up bug. We'll get that fixed.
As for the inconsistent use of lang tags between the simple SKOS statements and the SKOS-XL ones, we'll also address that. It's a bug too, but one that will require a little more untangling.
Background for anyone interested: We decided to remove the lang tags from the Names resources (this was something we wanted to do for quite some time but is a non-trivial change, requiring an entire reload), but wanted to maintain the lang tags for pretty much everything else. The inconsistency you noticed in the Subjects is clearly something that was missed.
Yours,
Kevin
-----Original Message-----
From: LC Linked Data Service Discussion List <[log in to unmask]> On Behalf Of Antoine Isaac
Sent: Monday, November 04, 2019 11:55 AM
To: [log in to unmask]
Subject: [ID.LOC.GOV] Questions about SKOS data and language tags
Dear all,
At Europeana we're trying to harvest LCSH's LOD when our providers use it. And we've spotted an oddity with respect to the use of language tags, which is a key aspect for us.
For example at
http://id.loc.gov/authorities/subjects/sh85085171.skos.rdf
How come that the simple SKOS skos:altLabel statements there have values without language tags while the extended SKOS-XL pattern indicates language for the same labels?
PS: and a less important question: how come that there is a handful of skosxl:altLabel statements with simple literal values (with language tags by the way) while this is not allowed in SKOS?
Thanks for the help,
Antoine
|