The present isssue stems from discussions concerning the PC module (see issue tickets 567 and 588) and aims to address a number of topics that have been raised as separate (but deeply intertwined) threads through the CRM SIG mailing list, in reference to the ontological status of the PC properties and the kinds of statements one can make about them (and how to do so as well).
The threads to be consulted are the following:
2. [CRM-sig] ISSUE 588 Implementing the .1 Properties of Base and Extensions in RDF , [A]
3. [Crm-sig] PC0_Typed_CRM_Property in CRMpc (repeated below for ease) [B]
4. [Crm-sig] NEW ISSUE: Statements about Statements. (repeated below for ease) [B]
[A] a summary of the discussions under this thread can be found under issue 588.
[B] Bibliographic references mentioned throughout the exchanges are listed below:
- Sikos, Leslie F., and Dean Philp, ‘Provenance-Aware Knowledge Representation: A Survey of Data Models and Contextualized Knowledge Graphs’, /Data Science and Engineering/, 5.3 (2020), 293–316 <https://doi.org/10.1007/s41019-020-00118-0>
- Hernández, Daniel, Aidan Hogan, and Markus Krötzsch, ‘Reifying RDF: What Works Well With Wikidata?’, in /Proceedings of the 11th International Workshop on Scalable Semantic Web Knowledge Base Systems Co-Located with 14th International Semantic Web Conference (ISWC 2015), Bethlehem, PA, USA, October 11, 2015./, 2015, pp. 32–47 <http://ceur-ws.org/Vol-1457/SSWS2015_paper3.pdf>
- Representing provenance and track changes of cultural heritage metadata in RDF: a survey of existing approaches <https://arxiv.org/abs/2305.08477>
PC0_Typed_CRM_Property in CRMpc - post by George Bruseker (29 March 2023)
Dear all,
When using the PC classes modelling structure we end up with a class node for a property which we can then modify with things like 'kinds' and
'modes' etc.
Since such a statement has meaning and comes from somewhere [e.g.: that someone did something in some capacity (PC14 carried out by ... P02 has
range E39 + P14.1 in the role of E55)] one sometimes needs to provenance this statement with an E13 attribute assignment. Ie we want to ground who
made this claim.
In theory this would be done with E13 pointing to the node in the typical fashion (p141, P140). However, the class PC0_Typed_CRM_Property is not
declared as a subtype of E1 CRM Entity in the PC extension file. As a result we cannot do this.
https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs
I would argue PC0_Typed_CRM_Property should be declared a subclass of E1_CRM_Entity. Then it would be consistent with the rest of the modelling.
Opinions?
Best,
George
PC0_Typed_CRM_Property in CRMpc - post by Pavlos Fafalios (5 May 2023)
Dear George,
An instance of a property class represents a statement / formal proposition. Could we thus say that it is also an E73 Information Object?
Would multiple instantiation provide a solution to the problem you describe? E.g.:
:painting_sistine_chapel
crm:P14_carried_out_by :Michelangelo .
*:statement1*
a crm:PC14_carried_out_by, *crm:E73_Information_Object* ;
crm:P01_has_domain :painting_sistine_chapel ;
crm:P02_has_range :Michelangelo ;
crm:P14.1_in_the_role_of :master_craftsman .
:attrAssign1
a crm:E13_Attribute_Assignment ;
crm:P140_assigned_attribute_to *:statement1*
... ... ...
Thoughts?
Have a good weekend!
Best,
Pavlos
PC0_Typed_CRM_Property in CRMpc --post by Martin Doerr (6 May 2023)
Dear Pavlos,
I don't think this is a good solution. Every statement in a knowledge base is an information object. That does not say however, what it refers to in the universe of discourse (or real world). The identity of the information object is the RDF file. The identity of Michelangelo, as stated in the file, means Michelangelo the person and not the URI as a string in that file. Isn't it?
This is still an issue to resolve: In CRMinf, a Proposition Set is regarded as Information Object, but this is not what we actually mean, we mean the "meaning" of that Information Object, i.e., its truth or not. As such, CRMinf is inconsistent. This is, I think, Issue 614.
Best,
Martin
PC0_Typed_CRM_Property in CRMpc --post by Pavlos Fafalios (8 May 2023)
Dear Martin,
I see your point, thank you for the explanation. Maybe, this was also the motivation for introducing the property classes? (instead of using standard
rdf reification): an instance of a property class intends to represent a specific relation in the real world, not a triple/statement in a knowledge
base (as in the case of rdf:Statement
*"An RDF statement is the statement made by a token of an RDF triple"*).
If this is the case, I suggest including an explanation in the RDFS of the PCs.
Best,
Pavlos
PC0_Typed_CRM_Property in CRMpc --post by Athina Kritsotaki (8 May 2023)
[in response to George's email]
Dear George, all,
I am not sure that the class PC0_Typed_CRM_Property should be a subclass of E1. In my understanding, this class implies a situation concluded in an epistemological context. I am also not sure if the provenance we are looking for in this set of statements is a kind of E13. I am just wondering.
BRs,
Athina
PC0_Typed_CRM_Property in CRMpc --post by George Bruseker (8 May 2023)
[in response to the emails by Martin and Pavlos]
Hi all,
I would argue that the safest thing to do is to make the PCs a subclass of E1 and then see where we go from there. I agree with Martin that it can't be an information object (because everything would be then) but I imagine we would have a debate about what each .1 actually ontologically is. What is certain is that by virtue of the fact of being something said in the universe of CIDOC CRM it is something sayable / mentionable. This is what E1 gives us, the most vague point of an object that can be pointed to and named, possibly classified. The problem is right now that we have something that is sayable in CIDOC CRM (PCxxx) but it is not referenceable. But this is a logical contradiction. Everything that can be said can be referenced and PCxxx can definitely be said.
For example, if I say that Bob was involved in the Production of Mona Lisa as Creator then this is something said / stated that is important, that has a real world referent, which has a definite meaning which is true or false etc. Ergo, it requires provenance. The basic mechanism for provenance in CRMbase is E13 and indicates that there was an agency behind something being asserted of something else.
Here the thing we want to talk about is the role and the role IS an instance of PC14. It's already an instance of a class so it should be referenceable. (Also one might like to put a bibliography for people who thought that Bob was Creator of Mona Lisa etc.)
So I would go exactly for Paulos' modelling but with this change:
:painting_sistine_chapel
crm:P01i_is_domain_of :role_of_michaelangeo_in_sistene_chapel_project
:role_of_michaelangeo_in_sistene_chapel_project
a crm:PC14_carried_out_by ;
crm:P02_has_range :Michelangelo ;
crm:P14.1_in_the_role_of :master_craftsman .
:attrAssign1
a crm:E13_Attribute_Assignment ;
crm:P140_assigned_attribute_to
:role_of_michaelangeo_in_sistene_chapel_project
... ... ...
PC0_Typed_CRM_Property in CRMpc --post by Martin Doerr (8 May 2023)
Dear All,
I don't think it is correct to make the PC classes entities. Even though formally an RDF class could be regarded as an entity, ontologically we distinguish entities and relationships. The E-R paradigm makes this distinction also formally clear. We model the properties with .1 properties in FOL as n-ary relationships, and not as individuals.
Making the PC classes CRM Entities is inconsistent with the FOL definition, which is the proper formalization. In other words, we would make a workaround for a missing feature in RDFS an ontological argument. We are again in the discussion to take RDFS as the definition of the CRM, and not as an implementation.
As a first step, we could introduce an "E0 CRM Relation", which would have as instances all properties and the PC classes. The ontological distinction between relations and entities is fundamental to the methodology of ontological analysis.
As a second step, we can start to investigate to which degree PC classes qualify as ontological individuals in their own right. If we start declaring a priori all PC classes as entities, we have later to justify and remove all those that are relations in the true sense. For instance, I cannot imagine the "being part of" a Physical Object for some time to become an entity, because it needs a timespan.
Best,
Martin
PC0_Typed_CRM_Property in CRMpc --post by Robert Sanderson (8 May 2023)
Perhaps for the first time, I agree with Martin and not George!
The PC classes are part of the ontological layer -- we don't say that classes or properties are descendants of E1. Or PC classes are T box (terminology) and not A box (assertions using that terminology).
(See - https://en.wikipedia.org/wiki/Abox)
I can see, however, that it would be useful to be able to refer to assertions in CRMInf and perhaps in Activity templates ... but then those assertions _are_ A box - the are the subject of the discourse, not the language in which the discourse is taking place. We have Attribute Assignment to talk about important activities that assert relationships or properties. And if we don't want to go to that layer of A box layer reification, then we have the partitioning pattern -- to assert a role of a
particular individual in an activity, we can identify the part of that activity that the person carried out and assert a role classification on it via P2_has_type.
Rob
PC0_Typed_CRM_Property in CRMpc --post by George Bruseker (08 May 2023)
Hi Rob and Martin,
But the point is not to make assertions about the property class itself but the instance of the property class.
The instance of PC14 says Bob was the creator, Bob was a faker... it is a regular abox assertion. And it has an identifier, necessarily.
The instances of PC classes are all already abox statements. They have just been modelled in an odd way where we don't account for their ontological substance. Being in a role is an ontological substance to define.
For me it is a big problem if there are statements in the CRM that can be made (Bob was the builder) but can't be discussed. The abox statement Bob was the builder is definitely in the domain of discourse and for that reason should necessarily as a matter of principle be referenceable.
Otherwise, CRMbase cannot state the provenance for a piece of knowledge like Da Vinci had the role of painter of Mona Lisa. It becomes impossible.
The abox information is in the PC14 instance.
Yes we can use the partitioning pattern which is fine, but it remains a question of technically what to do about PC classes and it seems only half baked if they aren't instances of E1. They fit the definition of instances of E1, "This class comprises all things in the universe of discourse of the CIDOC Conceptual Reference Model." Being in the role of the painter of Mona Lisa is, for me, a thing in the universe of discourse of the CIDOC Conceptual Reference Model.
The main thing is this is a technical extension to a technical extension to make things work and isn't a real ontological question to my mind.
If we wanted to do the ontological discussions we would have to open up the modelling box of worms, which is definitely another issue. I, for example, would like to be able to talk about the timespan of the property of something being part of something... but that's a broader issue :)
G
PC0_Typed_CRM_Property in CRMpc --post by Christian-Emil Smith Ore (8 May 2023)
Hi all,
The E13 Attribute assignment construct does not create any formal connection between an instance of E13 and the instance of the property it documents. We
have the property P177 assigned property of type (is type of property assigned): E55 Type.
It is no formal connection between this type and the property in question, however.
As far as I can see (which may be not very far) the FOL interpretation of CRM is, well, first order and we cannot quantify over predicates. In a second order logic this will be possible. Such a logic is undecidable, but may be part of it it can be implemented by some constructs.
Also: RDF(S) is an implementation technology. We can assume that there exists a implmentation function from the CRM-FOL to RDF(S), but this may not be a 1-1 function. Strange constructs like the PC0(?) may not have counterparts in CRM-FOL. Changing the ontology on the bases of special tricks used in the
implementation may not always be a good idea, but may inspire us to make well thought out and consistent changes in the ontology.
See (at least some of you) soon,
Christian-Emil
PC0_Typed_CRM_Property in CRMpc --post by Martin Doerr (8 May 2023)
Dear Christian-Emil,
Yes, and the formalization of Named Graphs is still missing, because theoreticians try to solve simultaneously Named Graphs for models particulars and for models of universals. I wonder if even SOL has the epistemic semantics of "who says that. In the meanwhile, Quad stores practically implement the necessary semantics of Named Graphs for particulars.
I would like to repeat that SOL is in general undecidable, but there exist quite well-defined decidable subsets. Nevertheless, the idea that SOL is always underdecidable has been used as killer statement for a lot of important developments in ontology engineering. To my understanding, we have no need for undecidable parts of SOL. Nicola Guarino uses SOL in his papers.
PC0_Typed_CRM_Property in CRMpc --post by Francesco Beretta (9 May 2023)
Dear Christian-Emil, All,
For the reasons I detailed in my other email, I totally agree with your point of view and would like to raise all possible caveats to this kind of mixing up quick and dirty implementation solutions and consistent conceptual modelling.
If we need more classes, even on a provisional and experimental perspective, I would strongly suggest to produce them and document them as such, with stable URIs, and then refine progressively the ontology and integrate it into the CRM family. Of course, a nice place to do this is ontome.net
Best
Francesco
PC0_Typed_CRM_Property in CRMpc --post by George Bruseker (9 May 2023)
Hi everyone,
To be clear I at no point suggested changing the ontology specification. I proposed making the rdfs for pc classes consistent logically. It presently
isn't. If this is too big a leap for some it is not a problem I will just implement it locally because I can't have unprovenanced statements.
Cheers
George
PC0_Typed_CRM_Property in CRMpc --post by Martin Doerr (10 May 2023)
Dear All,
I suggest to resolve the issue of referring to the provenance of .1 properties more specifically:
Solution a: Add properties to E13 to specify a .1 property. This may be more effective than the double indirection via PC class instance and 4 links of the E13 construct.
Solution b: Use RDF reification for this specific problem via the PC class.
We need to examine in both cases the inferences we want to maintain about the base property and its domain and range, and what the relevant query construct is.
Personally, I prefer solution c: Use the annotation model of CRM Dig, which goes via Named Graphs. This is much more performant and logically clearer, because Named Graphs are implemented as direct references to property identifier, and maintain a reference count for each one. This is an important logic in its own right. Inferences about the .properties would work in out ouf of a Named Graph, whereas the reification may need additional rules.
The query languages of Quad stores support them explicitly.
The latest version of 3M supports Named Graph definitions. This feature should be tested.
I would rather discourage E13 in the long term as a means to denote provenance generally and recommend a uniform use of Named Graphs. I am aware that not all RDF encodings support the feature. I that case we could resort to reification.
Opinions?
Best,
Martin
PC0_Typed_CRM_Property in CRMpc --post by Francesco Beretta (10 May 2023)
Dear Martin, George, All,
I would not dare to suggest some solution of this complex issue but let me hint to a couple of useful papers (among many others):
- Sikos, Leslie F., and Dean Philp, ‘Provenance-Aware Knowledge Representation: A Survey of Data Models and Contextualized Knowledge Graphs’, /Data Science and Engineering/, 5.3 (2020), 293–316 <https://doi.org/10.1007/s41019-020-00118-0>
- Hernández, Daniel, Aidan Hogan, and Markus Krötzsch, ‘Reifying RDF: What Works Well With Wikidata?’, in /Proceedings of the 11th International Workshop on Scalable Semantic Web Knowledge Base Systems Co-Located with 14th International Semantic Web Conference (ISWC 2015), Bethlehem, PA, USA, October 11, 2015./, 2015, pp. 32–47 <http://ceur-ws.org/Vol-1457/SSWS2015_paper3.pdf>
Once again, I would like to suggest carefully distinguishing between the CRM domain of discourse, in which the E13 class is conceptualized, and the issue of stating the provenance of the information modelled in the discourse domain, including instances of class E13 as part of the modelled domain.
For this last task (or domain of discourse), it would seems reasonable and in line with best practices to use the PROV model and the corresponding PROV-O ontology, a W3C recommendation. Or providing a specific extension of the CRM, compatible and aligned with the PROV model. But using PROV-O seems a good choice in order to facilitate interoperability.
There remains the more fundamental question of whether the current debate about RDF implementation is not in fact indicative of a more fundamental problem related to properties of properties and the implicit and richer information they contain, which cannot be adequately expressed in RDF without conceptualising them in terms of actual classes. Aren't these rather hybrid P(roperty)C(lasses), especially if they should be declared as subclasses of E1, to be considered as /de facto/ classes and not just properties? Because if they are just statements, then adopting one or the other form of existing RDF reifications practices seems to be the good way to go.
Best
Francesco
PC0_Typed_CRM_Property in CRMpc --post by Martin Doerr (11 May 2023)
Dear Francesco,
This is an excellent paper.
I cite: "However, reification has no formal semantics, and leads to a high increase in the number of triples, hence, it does not scale well. "
I agree with your proposals. Prov-O mapping is a must for CRM-SIG.
Best,
Martin
PC0_Typed_CRM_Property in CRMpc --post by George Bruseker (11 May 2023)
Dear Francesco, Martin,
Again for the record since I seem to be being read at cross purposes, when I mention the word 'provenance' I do not mean it in the sense of dataset provenance (to which prov o would apply). I mean that in the world to be described (the real world of tables charis cats dogs scholars ideas etc.) there are real world events in which people attribute things to things (see my previous email). This is content of the world to be represented in the semantic graph (not a metagraph about the graph). This is describable and is described in CIDOC CRM using E13 and its friends. If you want to say that there was a historical situation that someone in your department said (likely in the information system) that some attribute related two things you can do this with E13 (or I have completely misunderstood the CIDOC
CRM). This happens all the time in art history. One particular often arising case is an argument about who played what role in some object. Was Davinci the painter or was it Simon? This is just a hum drum case of needing to apply CIDOC CRM to real cases. Since E13 is a mechanism for so doing on all other statements, it would be a logical continuation that it could be used also on .1 statements. But for technical reasons it cannot, that is why I suggested a mild technical solution that makes the technical extension logically coherent. It is in this sense that I mean provenance and not in the metasense of the provenance of the data qua data, also an
exciting but other issue to my mind.
Cheers,
George
PC0_Typed_CRM_Property in CRMpc --post by Martin Doerr (11 May 2023)
Dear George,
I agree with you below about the historical aspects. The annotation model has the same historical aspect, but is not limited to a single link.
Let us discuss!
Best,
Martin
PC0_Typed_CRM_Property in CRMpc -post by George Bruseker (11 May 2023)
Dear Martin,
I agree that E13 is a poor man's solution to a complicated problem. But it is for some, the solution available. Other solutions like Inf for documenting historical argumentation and using named graphs is great as a possibility. Using prov o to represent the meta discursive level of the provenance of the dataset as such great. But my immediate interest was simple the humble ability of E13 to be able to point to all statements that can be made with precisely one link in CRM. I'll keep watching the space!
Cheers,
G
PC0_Typed_CRM_Property in CRMpc --post by Robert Sanderson (11 May 2023)
If the intent is that the assertion is in the discourse, and not a syntactic workaround for .1 properties that would be unnecessary if we had RDF* or property graphs, then I would say E13 is exactly the right approach to use. In comparison, I consider the PC classes to be just that - a syntactic work around needed in RDF and not part of the discourse. In LInked Art, in a discussion around uncertain attribution of artists and "style of" vs "school of", we posited the need for a property on E13 for this scenario. (Also the need for .1 on P11 for the same reason as we have
it on P14)
I would say that Dig's annotation is *not* the correct approach for several reasons:
- Named Graphs are a very specific technology that have never seen significant uptake and are likely (IMO) to decrease in usage once RDF* is formalized.
- Dig needs to be updated, and Annotation is (I would hope) likely to go away ... because ...it could just use the Web Annotation Data Model: https://www.w3.org/TR/annotation-model/
(And reification has all the problems discussed in this thread already)
Rob
PC0_Typed_CRM_Property in CRMpc --post by Martin Doerr (11 May 2023)
Dear Robert,
We have just created the new issue to discuss this in detail. We should prepare a detailed analysis, citing all pros and cons. May be we continue this discussion better in a subgroup?
Named Graphs are not a very specific technology, if we take the fact that all current triple stores are actually implemented as quad stores, regardless whether they call the construct "Named Graph" or "context". We have used and implemented this feature, and it is very performant. It runs on BlazeGraph as well. I think their is not a simple answer to that. Performance can become a major issue, when you have really a lot of data.
For the attribution of artists and "style of" vs "school of" etc. of the collection management system of the British Museum, the ResearchSpace Project had created a set of subproperties of P14 carried out by, which could be used as input for a roles vocabulary.
I did not propose to use Dig as is, but to consider the construct. The W3C annotation model is very interesting. We would need a connection to the Creation Event of making an annotation, and whose opinion it is, in order to make it CRM compatible. Why not allowing a Named Graph as target? We should compare the segment construct of the W3C annotation model with the METS <area> types and extensions we used. The Dig model was used to trace provenance of annotated area through transformations of digital objects. That was very important for exchanging research insights on 3D models. To be discussed!
We can extend E13 to Proposition Sets, which would be very important to describe consistently CRMinf and generalized observations. That would then be most effectively implementd via Named Graphs.
Opinions?
Best,
Martin
PC0_Typed_CRM_Property in CRMpc --post by Dominic Oldman (11 May 2023)
Hi
Just a quick question on this. We develop the model independently of technology. I can see that this discussion is getting technical. I currently implement propositions sets using RDF named graphs because we can and it works but it is not stipulated. Rob suggests that there are tech upgrades that might suit this issue better.
However, isn't it the case that we need to be able to implement in different ways (I don't currently know much about RDF*) depending on the systems we have?
How is RDF* implemented? - is it backwardly compatible with what we are all using?
Do we give more modelling credence to things that everyone uses? etc., etc. But aren't these questions the reason why we are technology independent?
Given this, my question is, - have we got to a stage when the modelling now depends on a particular technology?
Can someone provide some clarification on this?
Which solution is tech independent?
Are they all independent of this tech discussion? One is at least.
D
NEW ISSUE: Statements about Statements -- post by Martin Doerr (14 May 2023)
Dear Dominic, all,
Yes, I will always defend that modeling is technology independent, limited however to the degree that science and technology should at least provide the prospect of implementation in the near future, and some viable approximations immediately. We definitely started the CRM before the technology was generally available but expected. The primary criterion is that the model reflects our insight about the scientific discourse we target at. As such, I see the model-level discussion to be between reasoning about "proposition sets" versus a "single binary proposition". The technical discussion should be about best and most effective approximations, regardless popular or not. The effectiveness will depend on use cases and platform requirements.
Please let us know, who is interested in participating in a narrower subgroup for creating a document analyzing the alternatives.
Best,
Martin
- NEW ISSUE: Statements about Statements. --post by Dominic Oldmann (14 May 2023)
Hi Martin,
I would like to be involved.
Thanks,
Dominic
- NEW ISSUE: Statements about Statements. --post by Pavlos Fafalios (15 May 2023)
Dear Martin,
I'm also interested in participating in this group.
Best regards,
Pavlos
- NEW ISSUE: Statements about Statements. --post by Francesco Beretta (15 May 2023)
Dear Martin,
I'm also interested in participating in this work.
Best wishes
Francesco
- NEW ISSUE: Statements about Statements. --post by George Bruseker (15 May 2023)
I would like to see what is discussed. G
- NEW ISSUE: Statements about Statements. --post by Thomas Bottini (16 May 2023)
Hello,
I also would like to see what is discussed.
Many thanks.
- NEW ISSUE: Statements about Statements. --post by Béatrice Markhoff (16 May 2023)
Dear Martin,
I would like to follow this discussion too, please. Thanks.
Best regards
- NEW ISSUE: Statements about Statements. -- post by Manolis Peponakis (18 May 2023)
Dear Martin,
I am not a formal member of SIG but I would like to follow this discussion. So, if there is a separate list please let me know.
You might find useful a recently published article entitled “Representing provenance and track changes of cultural heritage metadata in RDF: a survey of existing approaches” https://arxiv.org/abs/2305.08477
Thanks
Manolis
NEW ISSUE: Statements about Statements. --post by Anaïs Guillem (19 May 2023)
I also would like to see what is discussed.
Many thanks.
NEW ISSUE: Statements about Statements. --post by Martin Doerr (15 May 2023)
You are all welcome!
I'll send you soon an outline of what I have in mind.
All the best,
Martin
----
Working group currently consists of:
- Martin Doerr
- Dominic Oldmann
- Pavlos Fafalios
- Francesco Beretta
- George Bruseker
- Anais Guillem
- Beatrice Markhoff
- Manolis Peponakis
- Gerald Hiebel (p.c.)
- Athina Kritsotaki (p.c.)
Posting an email by Martin Doerr (pc 27 May 2023)
I have uploaded some preliminary ideas at:
https://docs.google.com/
I suggest to follow roughly the order of elaboration:
- ontological/ epistemological problem
- formal representation
- implementations and performance (including existing practices and feasible ones)
please feel free from now on to comment and to add phrases, paragraphs proposed subsections in "suggestion mode" in the google document.
All the best,
Martin
In the 57th CIDOC CRM & 50th FRBR/LRMoo SIG Meeting, GH presented HW (a visualization of the statements in the example regarding the whereabouts of Nero during the Great Fire of Rome belief, which contains two contradicting beliefs, i.e., the belief of Suetonius that Nero was in Rome, and the belief of Tacitus, that Nero was in Antium). The content of the beliefs of Suetonius and Tacitus are represented as named graphs.
More details for the presentation, files used in the implementation and outputs can be found here.
MD shared a document outlining considerations for making statements about statements as part of a knowledge graph. The document can be found here.
Discussion points:
- No standard manner to represent Named Graphs. For this example, there would be a Jxx linking to the “Propositions of Suetonius” to whatever lies in its scope (set of properties).
- Through reification, one can only individually enumerate each proposition. But they cannot refer back to the entire set and determine its truth/falsehood (qua set).
- The attribute assignment reification cannot substitute the named graph construct, cannot negate sets of statements.
Decision:
The SIG voted in favor of the approach put forth by MD. The document will be further elaborated as proposed.
How to move forward:
- Assuming that the SIG considers named graphs necessary to evaluate a set of propositions bundled together (i.e., that are considered true or false taken together, rather individually), to assist MD with the document:
- HW assignment:
- AG: Share the graphical annotation in draw.io to represent the statements about statements that form part of the named graph (maybe define a default way to circumscribe the statements at hand), that can be picked up by the implementation that ETz has put together to derive triples from the draw.io diagrams.
- PF: will assist with drafting the text, will also take a look at other reification approaches
- AK: will collaborate for the text.
Marseille, October 2023