- 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