Re: Lists of tagged strings in RDF

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