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
statements.
Currently, there are several RDF-based approaches to talk about
statements, mainly: named graph, rdf-star and classic reification
methods[1].
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
identifiable.
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
semantic.
9. The semantics of RDF-star differentiate between asserted and embedded
triples
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
Best,
Nicola
[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? -
http://aidanhogan.com/docs/reification-wikidata-rdf-sparql.pdf
--
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.bruse...@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
CIDOC
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.bruse...@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.bruse...@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@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
