- From: Rumph, Frens Jan <mail@frensjan.nl>
- Date: Thu, 10 Jun 2021 19:37:03 +0200
- To: Christophe Debruyne <christophe.debruyne@gmail.com>
- Cc: SW-forum <semantic-web@w3.org>
- Message-ID: <CAH3f1B8Gzng7LVh6TcRziyeL=PPb9esv3XBq0UB8dBb_9cSaFw@mail.gmail.com>
Dear Christophe, Thank you for the pointer. I wasn't aware of this ontology! There are some elements missing from the vocabulary, but it comes a long way. But knowing that others went down this route is somewhat reassuring. As for the use of blank nodes: agreed, this is not necessary. Given the inability to delete them (with SPARQL) I am steering away from them anyway. Best regards, Frens Jan On Thu, Jun 10, 2021 at 1:08 PM Christophe Debruyne < christophe.debruyne@gmail.com> wrote: > MADS (https://www.loc.gov/standards/mads/rdf/) provides you a way to > represent parts of a name using a collection. A madsrdf:PersonalName has a > madsrdf:elementList that refers to a list (thus keeping order). In that > list, you can have various typed resources with a madsrdf:elementValue > containing the literals. > The nodes do not necessarily have to be blank. So this looks like your > second approach but using a vocabulary published by the Library of Congres. > With my best regards, > Christophe > > On Thu, Jun 10, 2021 at 12:39 PM Martynas Jusevičius < > martynas@atomgraph.com> wrote: > >> Why is the list syntax ( ) not satisfactofy? >> >> On Thu, 10 Jun 2021 at 12.07, Rumph, Frens Jan <mail@frensjan.nl> wrote: >> >>> Dear readers, >>> >>> I am investigating transitioning an application to use RDF. One >>> roadblock is how this application models names of persons. It supports >>> straight-forward full names as a single string, but also supports >>> decomposed names, e.g. person X has given name *Frens* followed by a second >>> given name *Jan* followed by the family name *Rumph*. >>> >>> Note that this is a crosspost of >>> https://stackoverflow.com/questions/65982459/rdf-modelling-of-list-of-name-elements >>> <https://stackoverflow..com/questions/65982459/rdf-modelling-of-list-of-name-elements>. >>> I hope to get some more >>> >>> The data structure is something like: >>> >>> ```java >>> enum Role { >>> ... >>> GIVEN_NAME, >>> FAMILY_NAME, >>> ... >>> } >>> >>> record NameElement(role: Role, value: String) {} >>> >>> record AnnotatedName(NameElement... elements) {} >>> ``` >>> >>> in order to be instantiated like: >>> >>> ```java >>> var name = new AnnotatedName( >>> new NameElement(GIVEN_NAME, "Frens"), >>> new NameElement(GIVEN_NAME, "Jan"), >>> new NameElement(FAMILY_NAME, "de Vries") >>> ); >>> ``` >>> >>> This allows reconstruction of the name into a string while at the same >>> time expressing the components of the name. So it captures the roles of the >>> elements of a name (e.g. given names, family names) *as well as* their >>> order (given names aren't first everywhere). Also, it allows expressing >>> multiple names. E.g. in multiple languages / scripts. Or even aliases used >>> in different areas of the world. >>> >>> I have toyed around with some RDF constructs, but none are really >>> satisfactory: >>> >>> ```turtle >>> # list of strings misusing data types as tags >>> :frens :name ( "Frens"^^:givenName "Jan"^^:givenName "de >>> Vries"^^:familyName ) . >>> >>> # list of blank nodes >>> :frens :name ( [ :givenName "Frens" ] >>> [ :givenName "Jan" ] >>> [ :familyName "de Vries" ] ) . >>> >>> # single blank node with unordered 'elements' >>> :frens :name [ a :AnnotatedPersonName ; >>> :fullName "Frens Jan de Vries" ; >>> :givenName "Frens" ; >>> :givenName "Jan" ; >>> :familyName "de Vries" ] . >>> ``` >>> >>> --- >>> >>> **Existing ontologies for HD names?** >>> Is there an existing ontology that covers such 'high fidelity'? FOAF and >>> vcard have some relevant properties, but aren't able to capture this level >>> of semantics. >>> >>> **Lists?** One major 'blocker' in migrating this approach to RDF is the >>> notion of order that is used. If at all possible, I'd like to stay away >>> from the List / Container swamp in RDF land ... >>> >>> I'd be grateful for any thoughts on the matter! >>> >>> Best regards, >>> Frens Jan >>> >>
Received on Thursday, 10 June 2021 17:39:24 UTC