I agree with all you say. As with any
data transformation, the importance is to correctly analyze the semantics
of the data upstream so that transformation and alignment doesn't distort
this semantics downstream. Otherwise denatured data will be virally disseminated
through Linked Data networks.
No doubt, having a common approach whenever
possible, I think, is possible. And you are right for the names in Archives
Hub, I think. In case of names that do not fit in the western traditional
separation, better keep the name as one string.
Re: EAD Revision Highlights
#3 - the naming of <part>s
Hi Anila,
I totally understand and accept that cultural differences mean that one
approach won't feel right for everybody. I don't think trying to create
something controlled for names that everyone has to use is going to work.
I think the approach should be more about knowing what other services and
projects are using - which vocabularies are out there and are widely used
- and then making a choice. Rather than making up your own local terms
without appreciating the wider context.
It does seems that the LInked Data approach is either to separate the name
out:
foaf:givenName Beatrice foaf:surname Webb
Or, for many names where this is not appropriate, to simply use one string:
foaf:name Aung San Suu Kyi
The EAC-CPF approach echoes this, as it allows for both approaches. But
if we do want to separate out a name into parts, having a common approach
where possible seems like a good thing.
Your email has made me think about this again, because we (on the Archives
Hub) generally have 'western' names, but where we have names that do not
fit into this type of separation, we should probably choose to maintain
the name as one string rather than apply separations that are not really
semantically correct.
> > Dear all, > > Let me just bring some *contextual* information related to the thoughts
that were given to this issue. I fully agree that while implementing EAC-CPF
(or handling names as controlled access points in EAD, or other formats)
we sooner or later come up with facing such a problem. However the issue
is not so straightforward to cope with. At the early stages of developing
EAC-CPF there were long discussions on the need of referencing parts of
a name by using a controlled vocabulary. And I have been among those who
pushed on this direction. But we didn't manage to come up with a
common agreement on the categories to use. The main reason was that there
are great variations all over the world in the ways of building names,
according to cultural and linguistic contexts and conventions. Categories
such as First name, Surname, etc., are not meaningful in all cultures. > > EAC-CPF was built as a tool to be used by any archival service for
encoding CPF descriptions, in compliance with the specific cultural and
linguistic context. Hence, for EAC-CPF the issue was settled on behalf
of having only <part> and @localType and leave to the local implementations
apply the categories that are meaningful in the cultural context of name
construction. > > Though it is most useful (and necessary) to semantically align or
map information contained in EAC-CPF tags with that contained in specific
fields/tags of other schemas, I think there is a difference between this
task and the endeavor of wanting to develop a globally valid vocabulary
for referencing parts of a name. > > Now, of course a lot of thought is given to that by librarians who
are so familiar with highly structured information. But it is not by chance
that only large categories as *name*, *numeration*, *dates*, *titles* and
the generic category *other information associated to the name*, are defined
at a high level for structuring names. Of course the parts of the name
itself can be further categorized, but precisely this categorization is
culture dependent. If you see RDA (9.2 to 9.6 for persons, for example)
reference is made to the devoted annex (F) dealing with instructions for
entering Arabic, Burma, Indian, etc. names, as parts of those names are
not necessarily categorized according to the occidental conventions. And
then for details on each national use “Names of Persons: national usages
for entry in catalogues” is referred to. > > It is however possible to launch a work on creating a controlled vocabulary,
but this should take into account all cultural traditions. > > Anila > > Anila Angjeli > Biblioth�que nationale de France > D�partement Information bibliographique et num�rique (IBN) > Quai Fran�ois Mauriac > F-75706 Paris cedex 13 > T�l.: 33.(0)1.5379.5395 > [log in to unmask] > > > > > > Message de : Jane Stevenson <[log in to unmask]>
>
28/10/2013 09:49
> Envoy� par : > Encoded Archival Description List <[log in to unmask]> > Veuillez r�pondre � Encoded Archival Description List <[log in to unmask]> > > Pour > [log in to unmask] > Copie > Objet > Re: EAD Revision Highlights #3 - the naming of <part>s > > > > > > HI Mike, > > Thanks very much for your response. That all makes sense. We may well
move from using @encodinganalog to @localType then, as its seems more appropriate
for what we do. > > > I also agree that creating a shared vocabulary for referencing
the parts of a name will be an important part of making archival description
function as Linked Data. We would want the same standard to be used
across EAC-CPF and EAD, as well as EAC-Functions, when that comes along,
etc. As such, it really needs to exist external to those standards,
and to be referenced as Ethan suggests from each. If ArchivesHub
were to take the lead on creating just such a vocabulary (nudge nudge),
it would be a wonderful contribution. > > I'm very keen to continue our Linked Data work - we've just made a
breakthrough with matching to DBPedia and it's great to see a long list
of our names matching to other data. I'll take on board your suggestion! > > cheers, > Jane. > > > > On 28 Oct 2013, at 01:51, Michael Rush <[log in to unmask] > wrote: > > > Jane, > > > > Your email nicely lays out the different ways in which <part>
could be used. One <part> will be required, but it may be repeated
as many times as necessary. An authorities librarian may regard a
name authority as a single part, but subjects are regularly broken down
into facets, which <part> will model much more accurately that the
common double-dash delimiter used in many EAD implementations. > > > > Re: using attributes to assign specific, agreed-upon meanings
to specific <part> elements, I agree, this is a real need. You
correctly identify @localtype as one such mechanism. Another will
be @encodinganalog. @encodinganalog should be used to indicate a
"same as" relationship between a given part and specific field
in another schema, say a MARC subfield. @locatype should be used
to subclass a given element, say a "surname" part. The
difference is subtle, but important. > > > > I also agree that creating a shared vocabulary for referencing
the parts of a name will be an important part of making archival description
function as Linked Data. We would want the same standard to be used
across EAC-CPF and EAD, as well as EAC-Functions, when that comes along,
etc. As such, it really needs to exist external to those standards,
and to be referenced as Ethan suggests from each. If ArchivesHub
were to take the lead on creating just such a vocabulary (nudge nudge),
it would be a wonderful contribution. > > > > Mike > > > > > > Participez � la Grande Collecte 1914-1918 > > Avant d'imprimer, pensez � l'environnement. >