[Crm-sig] Propose New Issue: Named Graph Usage Recommendations / Guideline Document

Nicola Carboni nic.carboni at gmail.com
Thu Jun 24 15:14:53 EEST 2021

Dear all,

In the context of the homework for this issue I report a bit of 
information about way to make statements about triples.

During the last conversation on the issue, I believe we did discuss the 
usefulness of formalising a way to talk about named graph. The 
conversation was born, if I remember correctly, from the survey made by 
GB about how we use named graphs and if we should standardise a way to 
do so.

I enlarge a bit the problem, as in my perspective what we are seeking to 
standardise, it is not only named graph but ways to talk about 

Currently, there are several RDF-based approaches to talk about 
statements, mainly: named graph, rdf-star and classic reification 

Named graph is the classical approach to group together a series of RDF 
statements and (possibly) make further statements about it. It extended 
standard RDF with a fourth element, an IRI, which is used to identify an 
RDF graph (the result is a quadruples). Named graph can be used in 
several ways and for several purpose as there is no attached semantics 
to them. They are used by systems to store technical data about the 
graph database itself, as well as a way to differentiate and group 
statements together. There is really not so much limit to their uses and 
they are just a mechanism of grouping statements together and made them 

Lately, RDF-star (ex RDF*) has been also proposed as another way to make 
statements about statements. RDF-star is a novel way, not yet W3C 
officially approved, to make statements about triples. While not 
officially approved, it is implemented and working across several graph 
databases. RDF-star started from the basic idea that should be possible 
to make statements about a single triple using a simple syntax, such as:

`<< <a> <b> <c> >> :assertedBy :Person `

Above, two statements are encoded: it exists a triple `<a> <b> <c>` and 
that triple is asserted by :Person

so we have a first triple:

subject: `<a>`
predicate: `<b>`
object: `<c>`

and a second triple:

subject: `<a> <b> <c>`
predicate `:assertedBy`
object: `:Person`

the operator `<<` `>>` are used to identify a triple which is used as 
subject or object of a RDF statement.
RDF-star can be recursive and used to nest more statements together and 
say, for example:

`<< << <a> <b> <c> >> :assertedBy :Person >> :source :uri  >>`

where three statements appear, that exist a triple `<a> <b> <c>`, that 
is is asserted by :Person and the source for such statement is to be 
found in a :uri.

A translation these last statements using a single-statement named graph 
would be:

<a> <b> <c> <#assertion1>
<#assertion1> :assertedBy :Person
<#assertion1> :source :uri

so what are the difference between the methods:

1. Named graph do not have any semantics attached to it. the lack of 
semantics in named graphs implies that statements about the graph do not 
really have to be about the content of the graph. For as much as it 
could be intuitive, it is not formally defined.
2. Named graph need identifier as proxy (so additional node)
3. Named graph are part of RDF 1.1 standards
4. RDF-star will be more aligned with property graph
5. RDF-star do not need identifier to define a graph
7. RDF-star are used for single-level statement, nor for annotating 
graphs (as in named graph)
8. RDF-star reuse and can be (in theory) completely aligned with RDF 
9. The semantics of RDF-star differentiate between asserted and embedded 
10. The semantics of RDF is referential opaque (if I remember correctly)

Both methods can be used to talk and make statements about triples. Is 
any of this useful? To me, very.

For example, In our current project, Visual Contagion, we are working 
towards the use of historical record (and computed visual similarity) 
that tell us about contact between artists and works of art to define 
possible visual transfers. We would like to differentiate between 
statements that have as source historical records, information derived 
from computed visual similarities and clustering, and interpretations 
based on these initial records. We will use named graphs for recording 
possible influences, and document the chain of information and sources 
behind an interpretations.

Another clear example of use on named graph in the past has been the 
recording of misattribution in paintings, and how their attribution has 
changed over time.

In both case, named graph were the tools we used to make statements 
about statements, but as mentioned above, there are other ways, and 
maybe in the future I will try to test RDF-star, or on property graph.

I would, therefore, not focus on the formalisation of named graph, but 
on the clarification/documentation of the way we talk about triples in 
CRM, how we can encode such information and mostly what is their 
context/validity. For example, RDF-start allow for the differentiation 
of asserted and embedded triples, making evident the context in which a 
triple is valid, while named graphs do not. If all triples are asserted, 
  It would be great to share common specifications in this respect, 
defining what is the context of a triple statements.

Hope it can be helpful for the discussion



[1] I am not going to talk about this really, as it has been discussed 
many time and considered a quite verbose solution, as well as 
problematic in term of implementation. For an overview of the methods, a 
great article by Aidan Hogan is this one: Reifying RDF: What Works Well 
With Wikidata? - 

Nicola Carboni
Visual Contagion
Digital Humanities - dh.unige.ch
Faculté des Lettres
Université de Genève
Rue des Battoirs 7, CH-1205 Genève

On 3 Mar 2021, at 7:51, George Bruseker wrote:

> Dear all,
> I'm pleased to report that this issue has made the official SIG issue 
> list:
> http://www.cidoc-crm.org/Issue/ID-526-named-graph-usage-recommendations-guideline-document
> For all interested parties to this issue with knowledge and 
> experience, a
> very warm welcome is extended to attend the session.
> and is scheduled to be discussed in the second session of the first 
> day of
> the upcoming SIG, that is on Monday, March 8, 2021.
> The official agenda due out soon.
> Best,
> George
> On Thu, Feb 25, 2021 at 10:20 AM George Bruseker 
> <george.bruseker at gmail.com>
> wrote:
>> Dear all,
>> Before the last SIG, together with CHIN, we proposed an issue on
>> discussing best practice in the application of named graphs by the 
>> CRM community. In order to empirically ground this conversation and 
>> build a
>> background understanding of the present state of the art, CHIN and 
>> myself
>> co-developed a survey which we shared to the list in order to get 
>> actual
>> practitioner feedback on the use of named graphs. The results of that
>> survey as well as preliminary conclusions regarding its content are 
>> listed
>> in the attached report. In the report you will find a link to the 
>> original
>> survey and the raw data resulting if of interest.
>> So the groundwork and homework is done to have a fruitful 
>> conversation on
>> this topic!We heartily look forward to discussing this issue at the
>> upcoming SIG and will make sure to invite all respondents to the 
>> survey to
>> attend the scheduled session. We look forward to the community based
>> discussion on this question and building best practices together.
>> Here is a link to the survey result report:
>> https://drive.google.com/file/d/1vUBsp-AUrdE0_61CpsqBymQEzyzLvMzh/view?usp=sharing
>> Sincerely,
>> George
>> P.S.: Sorry if this sends twice, the list bounced my email with a 
>> tiny
>> attachment, so I had to find a workaround. Hope this does the trick!
>> On Fri, Oct 30, 2020 at 2:07 PM George Bruseker 
>> <george.bruseker at gmail.com>
>> wrote:
>>> Dear all,
>>> Given the packed agenda of the CRM SIG, we were not able to talk 
>>> about
>>> named graphs during the course of this SIG.
>>> I would hope to move the conversation forward significantly between 
>>> now
>>> and the next SIG in parallel with the work on issue 382
>>> <http://www.cidoc-crm.org/Issue/ID-382-where-to-stop-documenting-the-provenance> 
>>> on
>>> provenance.
>>> To this end, together with CHIN, I have compiled a survey on named 
>>> graph
>>> use, that I would invite people/organizations in the community who 
>>> are
>>> interested in the question to answer. CHIN is actively researching 
>>> this
>>> issue and will compile the data and share it back to respondents and 
>>> the
>>> community in support of a general CIDOC CRM SIG recommendation on 
>>> the use
>>> of named graphs (similar to the RDF recommendation document work).
>>> The survey can be retrieved here:
>>> https://docs.google.com/forms/d/e/1FAIpQLSeIPyE6uZ5r32G4Ejznk5E6X4rkj45fuEzj_Z9QzL2R_F07zA/viewform
>>> Sincerely,
>>> George Bruseker
>>> On Thu, Oct 22, 2020 at 4:21 PM George Bruseker <
>>> george.bruseker at gmail.com> wrote:
>>>> Dear all,
>>>> As a complement to the work going on in issue 382 on where to 
>>>> document
>>>> and where not to document provenance, I suggest a parallel avenue 
>>>> of
>>>> research/work related to the implementation of named graphs for 
>>>> data sets
>>>> using CIDOC CRM. As named graphs are now commonly used in semantic 
>>>> data
>>>> management, it seems apropos as a community to have a 
>>>> recommendation of
>>>> good practice similar to what we have done with the RDF 
>>>> implementation
>>>> document (outside of the spec, but related to real world use).
>>>> This issue is something that is especially of interest to 
>>>> organizations
>>>> involved in and intending to implement aggregations of CH datasets 
>>>> where
>>>> the issue of named graphs have to do, inter alia, with both 
>>>> questions of
>>>> provenance but also questions of maintenance and updating of the 
>>>> semantic
>>>> data graph.
>>>> To this end, together with Philippe Michon and the team at CHIN, we 
>>>> have
>>>> been putting together a set of questions, to try to pick out the 
>>>> actual
>>>> practice of named graph usage in the CIDOC CRM community as a basis 
>>>> from
>>>> which to create a empirically grounded best practice
>>>> recommendation/strategy.
>>>> Time permitting, we would like to share our current ideas/questions
>>>> during the SIG, and then share a survey with the community.
>>>> Otherwise, we can continue this conversation virtually.
>>>> Best,
>>>> George

> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20210624/501643a7/attachment-0001.html>

More information about the Crm-sig mailing list