Print

Print



Hi Jane,

(sorry for being late in responding ...)

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.

Cheers,
Anila





Message de : Jane Stevenson <[log in to unmask]>
                    29/10/2013 11:59

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 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.

cheers,
Jane



On 28 Oct 2013, at 16:10, Anila Angjeli <[log in to unmask]> wrote:

>
> 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.
>


Participez � la Grande Collecte 1914-1918

Avant d'imprimer, pensez � l'environnement.