RISM: How/Where to understand the schema of RISM? & Are the blank nodes in the original code indispensable?

[candlecao]

Subject: Clarification on RISM Metadata and Schema

Hi Andrew, @ahankinson @Yueqiao12Zhang

We have primarily conducted a trial reconciliation (see https://github.com/DDMAL/linkedmusic-datalake/blob/main/rism/data/output/merged.ttl) for a small sample of RISM data. During the process, we encountered some metadata elements that are unfamiliar to us, which may impact the accuracy of our reconciliation with Wikidata.

For example, we came across prefixes such as (see https://github.com/DDMAL/linkedmusic-datalake/blob/main/rism/data/raw/output.ttl):

• @prefix ns1: <https://rism.online/api/v1#>

and properties:

• https://rism.online/api/v1#/hasDates
• ns1:hasHolding, ns1:hasMaterialGroup, ns1:hasRole, etc.

If we are unsure of their precise meanings, it could interfere with the reconciliation process. Would you be able to provide a clear reference or documentation outlining the original metadata schema for the RISM database?

Additionally, we noticed that the property values for ns1:hasRole, such as <http://id.loc.gov/vocabulary/relators/arr> and <http://id.loc.gov/vocabulary/relators/cmp>, are classified as properties within BibFrame. Wouldn’t it be more appropriate to define them as classes or instances instead?

Lastly, I believe that for the structure of embedded blank nodes, we need a more detailed specification of their semantic meaning. What are your thoughts on this?

Thank you for your time and insights!

[candlecao]

Subject: Necessity of Blank Nodes?
See https://github.com/DDMAL/linkedmusic-datalake/blob/main/rism/data/raw/rism-test-100000.ttl in n-triples format.
There are so many blank nodes because as far as I'm concerned, they are used for constructing hierarchy structure for properties.

In what cases/scenarios is it more suitable or even indispensable to use blank nodes instead of named graph?
I propose, this question actually reveals 2 different scenarios of using blank node:

1. Using blank nodes to represent an entity, which lacks a URI(IRI), (temporarily) and it's worthwhile to create a URI(IRI) for that entity.
   In such scenario, we absolutely can use "named graph" for refinement
   However, otherwise:
2. Using blank nodes to represent some special data structures, such as:
   2.1 to represent attributes on relationship between 2 entities or even more (we discussed it previously)
   2.2 to represent a hierarchical relationship for properties

regarding 2.2, it's quite common to engage in blank nodes for conversion of XML or JSON data documents into RDF, which is typical in RISM case. See https://github.com/DDMAL/linkedmusic-datalake/blob/main/rism/data/output/merged.ttl

So, at this step, I propose, we can evaluate whether it's "not worthwhile" to convert the blank nodes into entities with named graphs. @Yueqiao12Zhang
If really not worthwhile / indeed unnecessary, I think the current level of reconciled RISM RDF data would be sufficient at this stage. @fujinaga

[candlecao]

This is chatGPT's illustration:

Certainly! Below is your refined explanation, integrating the better example of rendering <address> rather than <composition><movements>.

---

In What Cases/Scenarios Is It More Suitable or Even Indispensable to Use Blank Nodes Instead of Named Graphs?

Your question reveals two key scenarios where blank nodes are appropriate:

1️⃣ Using Blank Nodes to Represent an Entity That Lacks a URI (IRI) Temporarily

✅ When to Use:

• When an entity has not been assigned a stable IRI yet.
• When data ingestion or transformation is in progress, and IRIs will be assigned later.
• When a local entity exists only in a specific context, but is not a first-class object in the knowledge base.

Example:

Before assigning an IRI to a newly identified composer, we can use a blank node:

_:composer1 a mo:Composer ;
            foaf:name "Unknown Composer" ;
            dct:created "2024-02-01" .

Later, once the composer has a stable IRI, we replace the blank node:

<https://example.org/composer/123> a mo:Composer ;
                                   foaf:name "Unknown Composer" ;
                                   dct:created "2024-02-01" .

🔹 Insight:
Yes, named graphs can replace blank nodes once an entity is well-defined and reusable.

---

2️⃣ Using Blank Nodes to Represent Special Data Structures

Blank nodes are essential in cases where:

• The entity is not independent enough to have a URI.
• Complex structured data needs hierarchical representation.
• Reified relationships require extra attributes.

---

2.1 Blank Nodes to Represent Attributes on Relationships

✅ When to Use:

• RDF triples are inherently binary (subject → predicate → object).
• Some relationships require attributes (e.g., timestamps, roles).
• Blank nodes provide structured reification without unnecessary URIs.

Example:

❌ Without a blank node, we lose information about the performance event:

wd:Q559 mo:performed wd:Q6607 .

✅ With a blank node, we capture additional attributes:

wd:Q559 mo:performed _:bn1 .
_:bn1 rdf:type mo:Performance ;
      mo:instrument wd:Q6607 ;
      mo:date "1784-12-10" .

🔹 Why not a named graph?

• The blank node models an event, not a separate entity.
• Named graphs are useful for tracking provenance, not for adding relationship attributes.

---

2.2 Blank Nodes to Represent Hierarchical Property Relationships

✅ When to Use:

• Converting structured data like XML/JSON to RDF.
• When sub-properties exist but are not standalone entities.
• When intermediate data elements are necessary for tree-like structures.

---

Example: Converting Addresses From XML to RDF

Consider the following XML data:

<person>
  <name>Johann Sebastian Bach</name>
  <address>
    <street>Fleischmarkt</street>
    <number>12</number>
    <city>Leipzig</city>
    <postalCode>04109</postalCode>
  </address>
</person>

✅ RDF Representation Using Blank Nodes

_:person1 a foaf:Person ;
          foaf:name "Johann Sebastian Bach" ;
          vcard:hasAddress _:address1 .
_:address1 a vcard:Address ;

vcard:street-address "Fleischmarkt" ;

vcard:postal-code "04109" ;

vcard:locality "Leipzig" .

---

🔹 Why Is This a Better Example?

• The address is not an independent entity—it belongs only to this person.
• A blank node preserves the nested structure.
• If we later need to track multiple sources of addresses, we could use named graphs instead.

---

🔹 When Are Named Graphs Preferable?

Use Case	Blank Node ✅	Named Graph ✅
Temporary entities (before assigning IRIs)	✅	❌
Reified relationships (events, attributions)	✅	❌
Hierarchical properties (XML, JSON conversion)	✅	❌
Provenance tracking (where data came from)	❌	✅
Versioning (historical records of an entity)	❌	✅
Multi-source integration (separate datasets)	❌	✅

---

🔹 Conclusion

✅ Your understanding is correct, and we can summarize it as follows:

1. Blank nodes are useful for representing temporary, context-dependent entities.
2. Blank nodes are essential for modeling structured data and attributes on relationships.
3. Named graphs are better for provenance, versioning, and multi-source data integration.

🚀 Final Takeaway: Use blank nodes for structure, named graphs for provenance & identity.

[ahankinson]

@prefix ns1: <https://rism.online/api/v1#>

This is simply automatically assigning a prefix to a namespace -- ns1:hasHolding == https://rism.online/api/v1#hasHolding.

Why are you trying to reconcile these things? I'm still unclear on your purpose. The principle of a data lake is to reconcile it at the point of use, not at the point of storage, so the alignment would depend on your intended use case.

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-a-data-lake

Are the blank nodes causing you problems? What are the specific problems they are causing you? I need some bullet lists of the specific issues to help you, because I can't necessarily figure it out from half a copied and pasted ChatGPT conversation.

[candlecao]

Why are you trying to reconcile these things?

--Because Ichiro hopes we reconcile as much as possible, including all properties and their property values @fujinaga (Hi, Ich, don't you?)

The blank nodes didn't cause us big troubles. But the meaning of some properties that connect the blank nodes isn't clear. I want to know the schema of RISM's metadata, so that we can better understand how the information is organized in RISM. Thanks

[fujinaga]

--Because Ichiro hopes we reconcile as much as possible, including all properties and their property values @fujinaga (Hi, Ich, don't you?)
What I want is to reconcile entities that are easily found on Wikidata. If a clear match is not found, then leave that as is.