Issue 402: representing compound name strings

Posted by Richard Light on 21/11/2018

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.

Posted by Robert Sanderson on 22/11/2018

My concern with this approach is that standard mechanisms for interacting with the data will not expect these sorts of compound values.  This would also affect other ongoing discussions, such as compound monetary amounts or other dimensions.

For example, if there are subfield indicators or XML elements embedded within a literal, rather than using the model to manage this information, queries at the model level will not work. If “Dr” is not a separate Appellation from “Snoopy”, with an appropriate Type associated with it to ensure it is known to be a prefix rather than a first name, it will be invisible to SPARQL or any other graph query language.

For names, which already support partitioning, the answer seems obvious to me that we should continue to use the model as intended.  The consistency for compound dimensions needs further discussion.  Similarly the value range for dimensions should follow existing patterns (P81a anyone?) rather than trying to embed one format within another.

Posted by Richard Light on 22/11/2018

On 21/11/2018 22:43, Robert Sanderson wrote:
>
> All,
>
> My concern with this approach is that standard mechanisms for interacting with the data will not expect these sorts of compound values.  This would also affect other ongoing discussions, such as compound monetary amounts or other dimensions.
>
> For example, if there are subfield indicators or XML elements embedded within a literal, rather than using the model to manage this information, queries at the model level will not work. If “Dr” is not a separate Appellation from “Snoopy”, with an appropriate Type associated with it to ensure it is known to be a prefix rather than a first name, it will be invisible to SPARQL or any other graph query language.
>
> For names, which already support partitioning, the answer seems obvious to me that we should continue to use the model as intended.  The consistency for compound dimensions needs further discussion.  Similarly the value range for dimensions should follow existing patterns (P81a anyone?) rather than trying to embed one format within another.
Martin's original suggestion involved identifying contexts where we could express compound values as a single string. This approach potentially has merit where such a string, as a whole, is in a format which is meaningful within existing systems and processible by existing software.  As you say, there is a direct trade-off between the convenience and structural simplicity of having a single string (and an associated single 'unit') and the [lack of] potential for native RDF querying of the contents of that string.

I think it is more of a loss to be unable to query on people with forename "Richard" than to be unable to query all dimensions involving '6 inches'.  So I agree that we should not pursue this particular line of thought.

As regards using an XML encoding within a literal, I think this would be a really bad idea. It would require the provision of an XML parser and support tools within the context of all RDF serializations (Turtle, JSON, ...).  RDF/XML has provision for embedded XML, but this wouldn't help for any other serialization of the RDF.

Posted by Martin on 22/11/2018

Dear Richard, Robert,

It is simply wrong that encoding structured data into an rdfs:Literal makes it invisible to SPARQL. It is exactly what xsd:dateTime does. The year, month, etc., is available to querying individually in SPARQL, not by magic but by a standard extension mechanism. It is a question to IT experts to tell us how to upload into the SPARQL code the respective string functions for other compounds. If we decide one standard way to encode the person name compounds, that would be quite feasible. Interoperability is in any case given with a trivial mapping, because standard SPARQL recognizes any custom datatype. Of course we would also provide standard string functions to take the compound apart. For this discussion we need a completely informed decision.

We must really be more aware how badly current RDF platforms still perform with longer property paths. There are good reasons why time, geometry and others are not encoded with rdf properties.

The first question we have to answer is A) how many compounds we need that must be queried component-wise. Then we should find B) the best XML representation regardless platforms. Then we discuss C) how that should go into RDFS.

I propose for A):

1) miles-yards.... American Standard Lengths "A mile is exactly 1.609344 kilometers. Yes, the mile has a metric definition." (https://www.mathsisfun.com/measure/us-standard-length.html)

2) Person Name compounds,

3) Street address compounds

I propose for B)

2) following either TEI or RDA guidlines. I do not propose to use MARC tags as is. The translation into XML elements is trivial syntactic sugar (and exists, I think). The relevant question is, if the analysis is effective or not.

I propose for C)

to find out if anybody has solved the problem already.

So, does anybody propose a good-practice analysis of name compounds?

Posted by Robert Sanderson on 28/11/2018

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.

In the 42nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 35th FRBR - CIDOC CRM Harmonization meeting, it was agreed that the crm-sig should look at the best practices adopted by international communities, and then re-address the issue of finding a meaningful way to represent massive compound names (such as properties, person street compounds etc)  in the next crm-sig meeting.

HW: NC, TV, MR (shall provide input about the meaning of the compounds), SS and RS are assigned with providing input.

Berlin, November 2018

Posted by Daria Hookk on 30/11/2018

Dear colleagues,
you completely forgot Russian names, where middle names does not exist, but middle part reffer to father's name,
hus mine is Daria Yurievna (father Yuri) Hookk.

Posted by Richard Light on 30/11/2018

Gordon,

Thanks for this. The page you cite demonstrates graphically the wide variety of approaches to presenting personal names for indexing and browsing.  In our SIG meeting earlier this week, we discussed this issue and agreed that what would interest us initially would be an analysis of the components of personal names.  As you say, the logical way to use such an analysis would be to split the name into its component parts and record each separately.

I suggest that we park this useful discussion for future reference, and CLOSE this issue.