Posted by George on 22/10/2020
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.
Posted by George on 30/10/2020
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 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
Posted by George on 7/12/2020
Dear all,
Just a reminder of the existence of this survey on named graphs:
https://docs.google.com/forms/d/e/1FAIpQLSeIPyE6uZ5r32G4Ejznk5E6X4rkj45fuEzj_Z9QzL2R_F07zA/viewform
Those who have knowledge and an opinion on the use of named graphs for managing cultural heritage semantic data are invited to take part. The anonymous data collected will be shared to the SIG in order to inform a discussion on the possibility of proposing a guideline on this topic.
Posted by George on 25/02/2021
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
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!
Posted by George on 3/3/2021
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…
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.
In the 49th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 42nd FRBR – CIDOC CRM Harmonization meeting, the SIG decided to continue working on producing guidelines for named graphs. The way to proceed is by determining the scope of the issue.
HW: MD to formulate the needs from the CRM perspective.
HW: ML, Sjoerd Siebinga, GB, GH, NC, DO to provide use cases
March 2021
Posted by Nicola Carboni on 24/6/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 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:
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.
Named graph need identifier as proxy (so additional node)
Named graph are part of RDF 1.1 standards
RDF-star will be more aligned with property graph
RDF-star do not need identifier to define a graph
RDF-star are used for single-level statement, nor for annotating graphs (as in named graph)
RDF-star reuse and can be (in theory) completely aligned with RDF semantic.
The semantics of RDF-star differentiate between asserted and embedded triples
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
In the 53rd CIDOC CRM & 46th FRBRoo SIG meeting, the SIG revisited this issue that had been sitting idle for quite some time.
HW was reassigned (to the same group essentially)
- HW by MD specifications have not been shared with the Sig
- HW on use cases has not been turned in either –NC was the only one to submit HW and it does not strictly speaking form a use-case, it’s more about a method.
Decision: Postpone the issue until HW has been turned in –send reminders.
Possibly return to RDF+ later on in the Sig.
May 2022