First, the same name in different languages is something that RDF
handles quite well: each string that is used as a label can be given
a language code, and you can have an official display form and "see"
forms (alternate labels) for each language. It actually is better
than what we have today, because RDF was designed for the global
As for transcribed forms, those are not the same as the information
about the series. Transcribed forms are information about the
instance, not the series, and should be treated as separate
information. They do NOT identify the series, they describe the
instance. In the past, a single string was used to fulfill way too
many roles, and often it was not clear what role it was fulfilling.
In particular, many strings could be used by a human to find a
related entity, but they could not be considered as identifying the
entity. We need to keep those functions separate. As I have said
before, I think that transcribed data needs to be clearly encoded as
such and should not be confused with identification of entities.
On 8/3/15 8:26 AM, Stephen Hearn wrote:
[log in to unmask]"
Some series are issued in more than one language,
with the series title being represented on each piece in the
language of each piece. When that's the case, the transcribed
display form of the series title would be one thing and the form
needed for indexing and display of the standard title in
user-friendly lists of series titles would be something else.
If there's an identifier for the series linked to the
standard form of the title (and any alternate language
variants), noting the relationship between the item and the
series identifier as part of a series statement might suffice
for access to the standard title; but if not, a cataloger
needs to be able to represent both these textual forms of the
series title in the bibliographic description. The
transcribed form would be better understood as a property of
the piece than as a relationship to the series, and vice versa
for the standard title.
[log in to unmask] http://kcoyle.net