[Crm-sig] ISSUE: representing compound name strings

Athanasios Velios a.velios at arts.ac.uk
Wed Nov 28 21:58:45 EET 2018


And some information from me about addresses:

OASIS xAL (extensible Address Language) as described here:

https://www.oasis-open.org/committees/ciq/download.shtml

The W3C Schema can be downloaded from here:

https://www.oasis-open.org/committees/ciq/Downloads/ciq_schemas.zip


All the best,

Thanasis

On 28/11/2018 14:47, Robert Sanderson wrote:
> Action from the SIG meeting to send information about partitioning of names:
>
> Personal Names:
>
> MARC has three subfields for name, in the bibliographic USMARC:
>
>     https://www.loc.gov/marc/bibliographic/bd100.html
>
>     Which has a lot of name fields, but also a lot of related things to
> a name (such as date of a work in subfield f)
>
> And the equivalent in MODS, for the type of namePart:
>
>      https://www.loc.gov/standards/mods/userguide/name.html#namepart
>
>      given, family, date, and termsOfAddress
>
> In the Getty AAT vocabulary, we have the following types of names
>
> http://www.getty.edu/vow/AATHierarchy?find=&logic=AND&note=&subjectid=300266386
>
>
> Which include both type of the complete name (e.g. noms de guerres) and
> parts of names (middle name).
>
> And name related concepts generally
>
> http://www.getty.edu/vow/AATHierarchy?find=&logic=AND&note=&page=1&subjectid=300404653
>
>
> Which includes prefix/suffix/title and similar.
>
> Place Names:
>
> For places, we have looked at the FGDC endorsed standard:
>
> https://www.fgdc.gov/fgdc-news/fgdc-endorses-address-data-standard
>
> https://www.fgdc.gov/standards/projects/address-data
>
> Which is … comprehensive, to say the least.  We then cherry-picked the
> bits that we thought most useful, given the level of data description
> that we need for cultural heritage purposes.
>
> Rob
>
> *From: *Crm-sig <crm-sig-bounces at ics.forth.gr> on behalf of Martin Doerr
> <martin at ics.forth.gr>
> *Date: *Wednesday, November 21, 2018 at 11:11 PM
> *To: *"crm-sig at ics.forth.gr" <crm-sig at ics.forth.gr>
> *Subject: *Re: [Crm-sig] ISSUE: representing compound name strings
>
> Dear Richard,
>
> XML is even better. The distinction between XML tags and MARC subfield
> markers is not so substantial. An XML file is still a string. The
> question is about RDF, putting a compound into rdfs:Literal.
> So, again, is there a good practice with XML elements ????
>
> Cheers,
>
> Martin
>
> On 11/21/2018 6:58 PM, Richard Light wrote:
>
>     On 15/11/2018 21:28, Martin Doerr wrote:
>
>         Dear All,
>
>         I would expect that the library or archival community do have a
>         good practice how to "squeeze" a compound name, such as :
>         "His Majesty Dr. Snoopy Hickup Miller Jr", with respective
>         separators, in a machine readable string, that could be used as
>         custom datatype in an rdfs:Literal as one instance of
>         Appellation, rather than defining all possible name constituents
>         as individual rdf properties.
>
>         Could be a MARC string? XML? TEI?
>
>         This would be very helpful for our users.
>
>     Martin,
>
>     I'm pretty sure that the most recent attempt at doing this will be
>     the subfield markers ($a, etc.) in MARC. which date from the era of
>     punched cards.  The requirement that all of the name appears in a
>     single string will rule out anything that might have been done in
>     XML (where you might typically use attributes or subelements) or TEI
>     (which is, after all, simply an XML application).
>
>     It's a nice idea, which follows the approach of encoding one
>     'compound' value as a single string, but I don't think we will find
>     a ready-made standard for it.
>
>     Richard
>
>
>
>         Best,
>
>         Martin
>
>     --
>     *Richard Light*
>
>
>
>
>     _______________________________________________
>
>     Crm-sig mailing list
>
>     Crm-sig at ics.forth.gr  <mailto:Crm-sig at ics.forth.gr>
>
>     http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
> --
>
> ------------------------------------
>
>   Dr. Martin Doerr
>
>
>
>   Honorary Head of the
>
>   Center for Cultural Informatics
>
>
>
>   Information Systems Laboratory
>
>   Institute of Computer Science
>
>   Foundation for Research and Technology - Hellas (FORTH)
>
>
>
>   N.Plastira 100, Vassilika Vouton,
>
>   GR70013 Heraklion,Crete,Greece
>
>
>
>   Vox:+30(2810)391625
>
>   Email:martin at ics.forth.gr  <mailto:martin at ics.forth.gr>
>
>   Web-site:http://www.ics.forth.gr/isl
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
This email and any attachments are intended solely for the addressee and may contain confidential information. If you are not the intended recipient of this email and/or its attachments you must not take any action based upon them and you must not copy or show them to anyone. Please send the email back to us and immediately and permanently delete it and its attachments. Where this email is unrelated to the business of University of the Arts London or of any of its group companies the opinions expressed in it are the opinions of the sender and do not necessarily constitute those of University of the Arts London (or the relevant group company). Where the sender's signature indicates that the email is sent on behalf of UAL Short Courses Limited the following also applies: UAL Short Courses Limited is a company registered in England and Wales under company number 02361261. Registered Office: University of the Arts London, 272 High Holborn, London WC1V 7EY



More information about the Crm-sig mailing list