[Crm-sig] Propose New Issue: Named Graph Usage Recommendations / Guideline Document
nic.carboni at gmail.com
Thu Jun 24 15:14:53 EEST 2021
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
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:
and a second triple:
subject: `<a> <b> <c>`
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
<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
 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? -
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
> 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.
> On Thu, Feb 25, 2021 at 10:20 AM George Bruseker
> <george.bruseker at gmail.com>
>> 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
>> co-developed a survey which we shared to the list in order to get
>> practitioner feedback on the use of named graphs. The results of that
>> survey as well as preliminary conclusions regarding its content are
>> in the attached report. In the report you will find a link to the
>> 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:
>> P.S.: Sorry if this sends twice, the list bounced my email with a
>> 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>
>>> Dear all,
>>> Given the packed agenda of the CRM SIG, we were not able to talk
>>> named graphs during the course of this SIG.
>>> I would hope to move the conversation forward significantly between
>>> and the next SIG in parallel with the work on issue 382
>>> To this end, together with CHIN, I have compiled a survey on named
>>> use, that I would invite people/organizations in the community who
>>> interested in the question to answer. CHIN is actively researching
>>> issue and will compile the data and share it back to respondents and
>>> 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:
>>> 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
>>>> and where not to document provenance, I suggest a parallel avenue
>>>> research/work related to the implementation of named graphs for
>>>> data sets
>>>> using CIDOC CRM. As named graphs are now commonly used in semantic
>>>> management, it seems apropos as a community to have a
>>>> recommendation of
>>>> good practice similar to what we have done with the RDF
>>>> document (outside of the spec, but related to real world use).
>>>> This issue is something that is especially of interest to
>>>> involved in and intending to implement aggregations of CH datasets
>>>> the issue of named graphs have to do, inter alia, with both
>>>> questions of
>>>> provenance but also questions of maintenance and updating of the
>>>> data graph.
>>>> To this end, together with Philippe Michon and the team at CHIN, we
>>>> been putting together a set of questions, to try to pick out the
>>>> practice of named graph usage in the CIDOC CRM community as a basis
>>>> which to create a empirically grounded best practice
>>>> 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.
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Crm-sig