Support RDF Lists

[kirkhess]

The LC profile editor and BFE supports a property type "list". We've implemented this in the Topic profile using the with the madsrdf:componentlist property. Componentlists are modelled in MADS and are used converting bib 6xx fields and auth records from MARC to RDF (Both BF and MADSRDF)

Basically this is what needs to happen:

• Modify profile schema to allow list as a property type
• Modify profile editor to have list as a property type option
• implement list control(s) in Sinopia editor

Example

All the complex subjects in ID show this pattern with both componentLists and elementLists: http://id.loc.gov/authorities/subjects/sh2009010295.html

<madsrdf:componentList rdf:parseType="Collection">
<madsrdf:Topic>
<rdf:type rdf:resource="http://www.loc.gov/mads/rdf/v1#Authority"/>
<madsrdf:authoritativeLabel xml:lang="en">Library buildings</madsrdf:authoritativeLabel>
<madsrdf:elementList rdf:parseType="Collection">
<madsrdf:TopicElement>
<madsrdf:elementValue xml:lang="en">Library buildings</madsrdf:elementValue>
</madsrdf:TopicElement>
</madsrdf:elementList>
</madsrdf:Topic>
<madsrdf:Topic>
<rdf:type rdf:resource="http://www.loc.gov/mads/rdf/v1#Authority"/>
<madsrdf:authoritativeLabel xml:lang="en">Barrier-free design</madsrdf:authoritativeLabel>
<madsrdf:elementList rdf:parseType="Collection">
<madsrdf:TopicElement>
<madsrdf:elementValue xml:lang="en">Barrier-free design</madsrdf:elementValue>
</madsrdf:TopicElement>
</madsrdf:elementList>
</madsrdf:Topic>
<madsrdf:Geographic>
<rdf:type rdf:resource="http://www.loc.gov/mads/rdf/v1#Authority"/>
<madsrdf:authoritativeLabel xml:lang="en">Canada</madsrdf:authoritativeLabel>
<madsrdf:elementList rdf:parseType="Collection">
<madsrdf:GeographicElement>
<madsrdf:elementValue xml:lang="en">Canada</madsrdf:elementValue>
</madsrdf:GeographicElement>
</madsrdf:elementList>
</madsrdf:Geographic>
</madsrdf:componentList>

Currently, you can choose an Authorized subject heading (see above) but you cannot construct a heading with the correct order w/o a list to keep them in order.

Implementing lists also allows for ordering other resources, such as contributions.

[michelleif]

@kirkhess will LC ever have URIs for constructed headings?

another strategy might be to use the rank property on repeated values for a field

[michelleif]

another question: is there other need for this, besides supporting composed subject headings?

[kirkhess]

@kirkhess will LC ever have URIs for constructed headings?

another strategy might be to use the rank property on repeated values for a field

Collections are a RDF feature (https://www.w3.org/TR/rdf11-mt/#whatnot) distinct from a container (rdf:type). They end up as arrays in JSONLD. The name isn't that important - I think I called this list because of ComponentList.

URIs for constructed headings would just replace the bnode for the collection with a uri, you'd still have the collection. It is possible to order a container with a property value instead of using a list - we probably would have to discuss the pros and cons of that method. In any case, MADS uses collections, BF uses collections, and if SHARE VDE is following our specs they also should have collections.

This should be one of the top priorities for your next work cycle. Matt Miller, Kevin or I can help if you have implementation questions.

[michelleif]

does LC BFE use collections for anything other than subject headings?

[kirkhess]

I believe this was an oversight in the profile spec - a 'resource' in the spec is for a RDF container which is why I added list as a type. BFE implements the 'list' type as array in the store.

Marc2bibframe2 converts using collections for 648-662 and 752 (which follows the rules for 662).
https://github.com/lcnetdev/marc2bibframe2/blob/master/xsl/ConvSpec-648-662.xsl https://github.com/lcnetdev/marc2bibframe2/blob/master/xsl/ConvSpec-720%2B740to755.xsl

The 6xx are similar to how MARC authorities are converted to MADSRDF. https://www.loc.gov/standards/mads/rdf/

[kefo]

@kirkhess will LC ever have URIs for constructed headings?

There has been some limited discussion of this. Personally, I'd like to see it happen, if even as an experiment. LCSH is a reality so we definitely need to figure out something that works. I've drafted plans and ideas about doing this on our side, but it is a matter of buy-in and a green light. I wish I could say something more definitive.

[kefo]

another question: is there other need for this, besides supporting composed subject headings?

Yes, but.

rdf:List (and rdf:Seq) are constructs that define ways to maintain order in RDF. Everyone hates rdf:List because it can be a bear to work with, in part because it produces so much noise. That said, JSONLD diminishes the pain because it treats rdf:List simply and, when not using compact JSONLD and processing the data as a JSON document/object (versus RDF), there is SPARQL sugar syntax that eases working with these constructs.

So the use of rdf:List may enter any discussion where order must be maintained. There are other techniques to handle order in RDF that do not rely on rdf:List or rdf:Seq, but rdf:List/Seq is what the RDF spec provides. LCSH components must be maintained in a certain order, so we use rdf:List.

For another possible "need," I've learned that one of the reasons we must have a bf:subtitle property is because subtitles are repeatable. That's all well and good (yay! repeating subtitles! So, so happy we're carrying this practice forward), and if that is in fact the case then at some point someone who really wants repeating subtitles will realize that those subtitles probably should be maintained in a specific order, at which point not only will there be a discussion about rdf:List but the current "solution" to this supposed need will result in a change to the model, but I digress, badly.

So, getting back to the question, Yes there are or likely will be use cases in the future where maintaining order is important but that might not be an issue if the pain of working with rdf:List lessens or some other method is agreed upon for capturing/maintaining order within the BF community.

[kirkhess]

Everyone hates rdf:List

I think the implementation of lists in both the n-triple and rdfxml serializations are particularly confusing, yet lists (and sets) are a core data structure in every programming language. I doubt anyone runs around saying how much they hate lists in ES6. Sinopia uses jsonld so you have @list available and this is easily done, especially when you use the jsonld npm package since it's baked in. If you roll your own serialization (aka Kevin) I can see where you would have a different perspective.

does LC BFE use collections for anything other than subject headings?

More on this: there's a bunch of MARC fields whose subfields are routinely concatenated in order for display. So while 'order' appears to be all over the format, it really shouldn't be the case in the RDF. I have noticed catalogers have a hard time with this change, and Kevin is correct this is probably something we're going to start expanding the use of lists when the entry order is actually meaningful not a display convention for an access point.

[michelleif]

see notes from discussion with user group on 11/4/19: https://docs.google.com/document/d/1-veUbkfJ-1YUfeXv5E6efBSY7iucyajamLl239MCnPo/

[michelleif]

from @timathom FYI, following up on the discussion of LCSH and RDF lists/sequences in the meeting this afternoon. The rdf:Seq approach seems relatively straightforward, and MADS/RDF accepts rdf:Seq as a valid range of the madsrdf:componentList property (which takes the LCSH heading as its object). I created this template (nice to be able to bookmark templates now!) with six sequence properties (rdf:_1 … rdf:_6): https://development.sinopia.io/editor/Yale:RT:BF2:Topic. Personally, I’ve never created an LCSH heading with more than six elements. Here’s a resource with URIs representing the heading “Graphic arts--Spain--Galicia (Region)--History--20th century--Exhibitions”: https://trellis.development.sinopia.io/repository/yale/2d6dda8d-eb46-46e0-b1d7-f498eb59a6ed (edited) The JSON-LD algorithm, when converting from Turtle, outputs the following:

{
  "@context": {
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@graph": [
    {
      "@id": "https://trellis.development.sinopia.io/repository/yale/2d6dda8d-eb46-46e0-b1d7-f498eb59a6ed",
      "@type": [
        "http://www.loc.gov/mads/rdf/v1#ComplexSubject",
        "http://id.loc.gov/ontologies/bibframe/Topic"
      ],
      "http://sinopia.io/vocabulary/hasResourceTemplate": "Yale:RT:BF2:Topic",
      "http://www.loc.gov/mads/rdf/v1#componentList": {"@id": "_:fe03fa868b2aa4b1e86e9cdbb23e08cd2b1"}
    },
    {
      "@id": "_:fe03fa868b2aa4b1e86e9cdbb23e08cd2b1",
      "@type": "rdf:Seq",
      "rdf:_1": "http://id.loc.gov/authorities/subjects/sh85056474",
      "rdf:_2": "http://id.loc.gov/rwo/agents/n79006971",
      "rdf:_3": "http://id.loc.gov/rwo/agents/n79089622",
      "rdf:_4": "http://id.loc.gov/authorities/subjects/sh99005024",
      "rdf:_5": "http://id.loc.gov/authorities/subjects/sh2002012476",
      "rdf:_6": "http://id.loc.gov/authorities/subjects/sh99001275"
    }
  ]
}

[kirkhess]

I wonder if there's someone whose written up a critique of rdf:Seq? RDF/XML is really the only format to provide native support for containers (rdf:Alt/Bag/Seq). JSONLD doesn't support the full RDF datamodel - the instructions on Lists and Sets in 1.1 don't seem to address this specifically.

The way we implemented componentList we haven't used rdf:Seq so perhaps that's on us to address the confusion since you could do either with a componentList right now. JSONLD didn't really exist when MADS was developed so perhaps we need to rethink that particular range.

[michelleif]

@justinlittman does your recent work on ordering of templates fix this issue?

[justinlittman]

It helps, but we still need UI support for re-ordering.

[justinlittman]

The work in #2358 adds support for specifying a property as ordered, in which case the order of its values will be maintained (using an RDF collection). Currently, additional work is needed to support re-ordering of values.

[michelleif]

what is left from this ticket? re-order repeating literal values in a field with attribute "ordered", without having to delete and re-add?

we don't really support complex subject headings though. you could add subject elements and order them. but you couldn't for example add 2 complex subjects in one field, just a set of individual subjects that are all ordered in one list.

[michelleif]

example in support of remaining work on this ticket: you want to put 2 values in "Statement of responsibility" field. the order is significant.

I think it's significant for display, in a discovery system. But I'm not sure if in a true linked data system it would still be significant.

[NancyL]

PCC would like full support for complex LCSH headings. Ordering helps a bit, but does not link the elements of the subject heading together, but just orders them--it ends up looking like FAST--and that is not LCSH. Also, as mentioned above, this only works if there is only one subject heading; it is not possible to create multiple SH this way.

[justinlittman]

I once understood the structure of LCSH, but that has long since left my head. Is there a primer on LCSH so that the devs can better understand these requirements?

[NancyL]

Hmm, I'll ask around, but mostly it's taught individually. The manual itself is huge. But the main points:

1. Headings are pre-coordinated by the cataloger, meaning that all the pieces of the heading are put together in a long, subdivided string when cataloging takes place
2. The primary heading may or may not have a built-in subdivision
3. The place, date, form subdivisions must be in a particular order following the primary heading

[michelleif]

1) does PCC want Sinopia to validate that the headings are constructed properly according to LCSH rules? 2) is there a way we could adapt the work LC has already done for the BFE?

[justinlittman]

Can the LCSH be expressed in the resource template and is the resulting RDF correct? Trying to understand if this has to do with our modeling of RDF or is a UI issue.

If UI, can imagine creating a special LCSH component.

[NancyL]

You mean currently? No.

---

From: Justin Littman @.> Sent: Monday, March 15, 2021 5:50 PM To: LD4P/sinopia_editor @.> Cc: Nancy Lorimer @.>; Comment @.> Subject: Re: [LD4P/sinopia_editor] Support RDF Lists (#1312)

Can the LCSH be expressed in the resource template and is the resulting RDF correct? Trying to understand if this has to do with our modeling of RDF or is a UI issue.

If UI, can imagine creating a special LCSH component.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/LD4P/sinopia_editor/issues/1312#issuecomment-799860695, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGXZNQR3DCOZHQNKAIRCSDTD2TO7ANCNFSM4IWPA3SQ.

[justinlittman]

Can you provide some RDF examples of what you can currently express in Sinopia and what you would like to be able to express in RDF? Would an LCSH just be an ordered list of URIs?

[justinlittman]

Closing since support for lists is implemented. If additional support for LCSH is required, it can be ticketed separately.