- From: thomas lörtsch <tl@rat.io>
- Date: Fri, 17 Sep 2021 16:33:54 +0200
- To: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
- Cc: Fabio Vitali <fabio.vitali@unibo.it>, "public-rdf-star@w3.org" <public-rdf-star@w3.org>, Alessio Rolfini <rolfini@gmail.com>
- Message-Id: <E046E7C2-4C07-46B5-BE59-D8A2542D7372@rat.io>
> On 17. Sep 2021, at 08:18, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
>
> Dear Fabio,
>
> it took me some time to process your email (and I must confess that it still need some processing).
>
> One first remarks, though, which is quite independant from RDF-star (for the moment):
>
> why did you feel the need to "rewrite" the predicates in your conjectures? Why not simply used a named graph? From what you wrote, it seems to stem from the misconception that named graphs are asserted, which they are not.
>
> More precisely, while the RDF specification defines the semantics of a single RDF graph [1], it does *not* defines the semantics of an RDF dataset [2]. In other words, while the semantics of a Turtle file is well defined, the semantics of a TriG file is unspecified. Different alternatives of what the semantics of datasets *could* be have been explored [3]. Some of them (3.3 in particular) make named graph a good fit, I think, for your notion of conjecture, without requiring additional processing or syntax.
Some of them also make a good fit for explainable AI or versioning.
Why instead use RDF-star and make it almost as tedious as RDF standard reification for the overwhelming majority of use cases which it was positioned and expected to replace?
Also why the optimism that the proposed semantics for RDF-star won’t suffer a similar fate as the proposed semantics for Named Graphs per the so named 2005 paper by Carroll et al.? The proposed Named Graphs semantics from that paper did put a much lesser burden on the user than the proposed RDF-star semantics, still it has seen very little uptake among the practitioners.
Thomas
> best
>
> [1] https://www.w3.org/TR/rdf11-mt/
> [2] https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-dataset
> [3] https://www.w3.org/TR/rdf11-datasets/
>
> On 25/08/2021 18:07, Fabio Vitali wrote:
>> Dear editors and contributors to the document "RDF-star and SPARQL-star - Draft Community Group Report 18 June 2021" (https://w3c.github.io/rdf-star/cg-spec/editors_draft.html )
>>
>> Olaf Hartig suggested that I submit this proposal to this mailing list as the best possible forum for discussion. This message contains a (unfortunately, rather long) proposal to extend the reach and expressive power of the RDF* language. The basis for this proposal is an extension to RDF for expressed but not asserted graphs, that we call Conjectures.
>>
>> It is my understanding that while the fundamental focus of the RDF* proposal concerns the identifiability of individual RDF triples and their use as subjects and objects of other triples, one of the consequences of this feature has been the need to extend the coverage of the proposal and discuss about expressing statements without asserting them. Overall, I believe that this part of RDF*, the one discussing the existence and differences between embedded triples, asserted triples, and annotations, nicely complements with Conjectures, and an integration of the two approaches could be very interesting for many different expressive needs.
>>
>> All in all, the modifications to the RDF* proposal as stated in the July 1st 2021 drafts would be fairly limited, and yet the number of additional advantages would be striking:
>> 1 maintain the main focus and the main approach of the current RDF* draft;
>> 1 create a symmetry between triples and graphs when expressing without asserting statements;
>> 2 support a trivial querability of embedded triples and graphs;
>> 3 provide an identification means for annotations;
>> 4 allow the embedding of annotations;
>> 5 allow annotations of embedded annotations, and cascading of embeddings and annotations.
>>
>> In the following I present myself (section 1), then introduce you to conjectures (section 2), a proposal that is compatible, complementary and (in a few specific ways) more flexible than RDF* with regards specifically to the representation of the differences between asserted vs. embedded triples (vs. graphs). In section 3 I point out main differences and similarities between the RDF* notion of embedding, and Conjectures. In section 4 I introduce a few situations that are culturally and scholarly very important, yet non expressible with RDF* embeddings and annotations but expressible with conjectures. In section 5 I list a few real life examples from my past experience in digital humanities, and in section 6 I propose a simple approach to extend the RDF* draft to include the main points of conjectures and extend its reach about non-asserted statements.
>>
>> In short, I believe that the main strength of RDF* (the ability to reify individual triples) and the main strength of conjectures (the ability to express graphs without asserting them) can complement each other and generate a very solid contribution.
>>
>> I am aware that the following will be a rather long read, for which I apologize in advance. I hope I am able to make it worth your time to go through it.
>>
>> Fabio Vitali
>> (with Alessio Rolfini)
>>
>>
>>
>>
>> 1 Presentation
>> ==============
>> My name is Fabio Vitali, and I am full professor in Web Technologies at the University of Bologna (Italy). I have been working for 20+ years in web and related topics, I have been AC at the W3C for years for the University of Bologna, and I was involved in the past in web standards, notably XML Schema 1.1 (now a W3C Recommendation) and the integration between RDF and Topic Maps. More recently, I was co-Program Chair of EKAW 2016 in Bologna. Outside of W3C, I am the main technical author and maintainer of the OASIS Standard LegalDocML Technical Committee, Akoma Ntoso, the most popular XML representation format for legal and legislative documents, adopted by a large number of Parliaments and Governments around the world (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legaldocml).
>>
>> I am one of the authors of the paper "Contextual conjectures for expressing RDF triples without asserting them", coauthored by colleagues Gioele Barabucci (NTNU, Norway) and Francesca Tomasi (Department of Italian Philology, University of Bologna), in which we proposed an extension to RDF, to Trig, and to Sparql for the representation of non-asserted RDF statements. The paper was submitted to WebConf21, rejected because of the lack of a mature formal model, and Olaf Hartig was so kind as to reveal his identity as a reviewer and to suggest a contact. I sincerely appreciated his (just) criticisms and his offer.
>>
>> It took me several months to follow up on his invitation and to write this, because I wanted to be sure to have a robust proposal, and in the meantime I was able to follow the evolution of the specific aspects of this group's effort, RDF* and SPARQL*, that covers some of the ground of conjectures as we proposed in the rejected WebConf paper.
>>
>>
>>
>>
>>
>>
>>
>>
>> 2 A short introduction to conjectures
>> =====================================
>> A conjecture is, by construct, a special kind of RDF graph containing triples whose truth values are not available. Thus conjectures are similar to embedded triples in RDF*, i.e., triples that are expressed but not asserted. Yet, conjectures apply to RDF graphs instead of individual triples.
>>
>> The extension of the syntax of Trig to support conjectures (not that syntax matters a lot to us) is very simple: you just prepend a "CONJECTURE" in front of the graph you want to conjecture. None of the triples contained in the graph is therefore asserted, but just expressed for further exploration.
>>
>> Our standard example is about the attribution of the play "Hamlet": Samuel Johnson asserted that "Hamlet" was written by William Shakespeare, while J. Thomas Looney asserted that it was written by Edward De Vere, 17th Earl of Oxford [*]. Also, scholars expect that at most one of these two attributions is true, since we know that Edward De Vere and William Shakespeare were two different individuals and they did not work together.
>>
>> [*] This is the so called "Oxfordian theory of Shakespeare authorship", see https://en.wikipedia.org/wiki/Shakespeare_authorship_question and more specifically https://en.wikipedia.org/wiki/Oxfordian_theory_of_Shakespeare_authorship
>>
>> Using conjectures, we can specify these statements as in the following (I am assuming that the right prefixes, e.g. for Dublin Core and Prov-O, are specified):
>>
>> ```
>> [1] CONJECTURE :conjecture01 {
>> :Hamlet dc:creator :WilliamShakespeare .
>> }
>> :conjecture01 prov:wasAttributedTo :SamuelJohnson .
>>
>> [2] CONJECTURE :conjecture02 {
>> :Hamlet dc:creator :EdwardDeVere .
>> }
>> :conjecture02 prov:wasAttributedTo :JThomasLooney .
>> ```
>>
>> Since in this specific case the content of each graph is composed of a single triple, these statements can be equivalently expressed in RDF*, if I am correct, as follows:
>>
>> ```
>> [3] << :Hamlet dc:creator :WilliamShakespeare >> prov:wasAttributedTo :SamuelJohnson .
>> [4] << :Hamlet dc:creator :EdwardDeVere >> prov:wasAttributedTo :JThomasLooney .
>> ```
>>
>> Yet, differently from embedded triples in RDF*, the equivalent representation in plain RDF of Conjectures DOES NOT USE REIFICATION.
>>
>> In fact, Conjectures NEVER reify the conjectured triples: rather, they postulate freshly minted predicates (used exactly once) that are *a form of* to the original predicates that are being conjectured (e.g., see `aaa:creator` and `bbb:creator` in the following example) and that are connected to them through a special relation, called `conj:isAConjecturalFormOf` [**], as follows:
>>
>> ```
>> [5] GRAPH :conjecture01 {
>> :Hamlet aaa:creator :WilliamShakespeare .
>> aaa:creator conj:isAConjecturalFormOf dc:creator.
>> }
>> :conjecture01 prov:wasAttributedTo :SamuelJohnson .
>>
>> [6] GRAPH :conjecture02 {
>> :Hamlet bbb:creator :EdwardDeVere .
>> bbb:creator conj:isAConjecturalFormOf dc:creator.
>> }
>> :conjecture02 prov:wasAttributedTo :JThomasLooney .
>> ```
>>
>> [**] In the rejected WebConf21 paper, conj:isAConjecturalFormOf was called conj:isConjecturallyEquivalentTo. The old name suggested an idea of equivalence that we then decided was inappropriate, and therefore we subsequently replaced it with this new name.
>>
>> In graphs [5] and [6], neither conjecture is asserted, and rather they are both just expressed in a hypothetical manner: their actual truth value is unknown.
>>
>> Over time, the scholarly community by and large has turned against the Oxfordian theory, and has expressed its opinion that it was William Shakespeare that wrote Hamlet and therefore that Samuel Johnson was right. To handle this situation, that a conjecture is being trusted while the competing ones aren't, Conjectures supply a special construct that actually asserts a conjecture, called "collapse to reality" [***]. Again I am not a great fan of our syntax, but here it goes:
>>
>> ```
>> [7] COLLAPSED CONJECTURE :conjecture01 {
>> :Hamlet dc:creator :WilliamShakespeare .
>> }
>> :conjecture01 prov:wasAttributedTo :SamuelJohnson .
>>
>> [8] CONJECTURE :conjecture02 {
>> :Hamlet dc:creator :EdwardDeVere .
>> }
>> :conjecture02 prov:wasAttributedTo :JThomasLooney .
>> ```
>>
>> [***] The term comes from the quantum mechanics term _collapse of the wave function of a particle_, i.e., the effect of an observation from the external world to reduce multiple eigenstates of a particle to a single one. Thus we use it to make a parallel with the operation of reducing the superposition of multiple independent conjectures to a single one which is then considered as true.
>>
>>
>> Collapsed conjectures are similar, but not equivalent to annotated triples in RDF*. In fact, items [7] and [8] above are similar but not equivalent to:
>>
>> ```
>> [9] :Hamlet dc:creator :WilliamShakespeare {| prov:wasAttributedTo :SamuelJohnson |} .
>> [10] << :Hamlet dc:creator :EdwardDeVere >> prov:wasAttributedTo :JThomasLooney .
>> ```
>>
>> In particular, if I am correct, [9] is plainly equivalent to:
>>
>> ```
>> [11] :Hamlet dc:creator :WilliamShakespeare.
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasAttributedTo :SamuelJohnson .
>> ```
>>
>> where the two triples are completely independent of each other, and the first one simply happens to be used as subject of the second one.
>>
>> In our proposal, on the other hand, asserted graphs are not simply placed next to conjectured graphs, but are in fact explicitly connected to them, so that it is possible to track which conjecture was collapsed, and, as we'll see in section 4, to conjecture conjectures and to conjecture collapses. For instance, [7] is equivalent to something slightly more complex:
>>
>> ```
>> [12] GRAPH :conjecture01 {
>> :Hamlet aaa:creator :WilliamShakespeare .
>> aaa:creator conj:isAConjecturalFormOf dc:creator.
>> }
>> :conjecture01 prov:wasAttributedTo :SamuelJohnson .
>>
>> GRAPH :collapseOfConjecture01 {
>> :Hamlet dc:creator :WilliamShakespeare .
>> :collapseOfConjecture01 conj:collapses :conjecture01 .
>> }
>> ```
>>
>> The first graph is just the original conjecture, while the second is the actual collapse. Not only such collapse states the conjectured triples (just like RDF* annotations do), but it also connects itself to the conjecture through the `conj:collapses` predicate. We usually place this connection within the collapsing graph for simplicity, but this is not required.
>>
>> As I will try to show later on, there are good reasons to maintain a connection between the embedded triples and their corresponding asserted ones, and I believe conjectures provide a good justification of that.
>>
>>
>>
>>
>>
>>
>>
>>
>> 3 Similarities and differences between RDF* and conjectures
>> ===========================================================
>>
>> 3.1 Individual triples vs. graphs
>> ---------------------------------
>> Both RDF* and conjectures can be used to express statements without asserting them. The most visible difference that I can see is that RDF* applies to individual triples, while Conjectures apply to graphs. Thus the approaches are complementary and compatible with each other, and I think that focussing only on individual triples may be limiting just as much as focussing only on whole graphs.
>>
>> 3.2 Reification vs. newly minted predicates
>> -------------------------------------------
>> Conjectures never reify triples nor graphs. I believe that the complexity inherent to reification makes it quite hard to fully develop the concepts connected to expressing triples without asserting them, and later on I will make a few examples in that regard. On the other hand, newly minted predicates associated to the original one through a specific predicate, (conj:isAConjecturalFormOf) provide in my view a more solid groundwork for non-asserted statements, simpler to grasp and more flexible in case of more complex representations (as I'll try to show in sections 4 and 5).
>>
>> 3.3 Annotated triples vs. collapses
>> -----------------------------------
>> In RDF*. an annotation is just a syntactical shorthand for the same triple being embedded and asserted at the same time: there is no specific relationship between the two triples. A collapse, on the other hand, adds an explicit relationship between the two triples so that it is possible to track and identify exactly which embedded triple is being asserted. While this may not be necessary for individual triples, it comes handy whenever conjectural graphs contain multiple statements with some possible overlaps. For instance:
>>
>> ```
>> [13] COLLAPSED CONJECTURE :conjecture01 {
>> :Hamlet dc:creator :WilliamShakespeare .
>> :Hamlet dcterms:created "1603" .
>> }
>> :conjecture01 prov:wasAttributedTo :SamuelJohnson .
>>
>> [14] CONJECTURE :conjecture02 {
>> :Hamlet dc:creator :EdwardDeVere .
>> :Hamlet dcterms:created "1603" .
>> }
>> :conjecture02 prov:wasAttributedTo :JThomasLooney .
>> ```
>>
>> I added two more identical statements in to each conjecture. By collapsing the first one, we are explicitly deriving from :SamuelJohnson both the authorship attribution and the creation dates of :Hamlet. This would not be possible with RDF* annotations.
>>
>>
>>
>>
>>
>>
>>
>> 4 Additional complexities
>> =========================
>>
>> 4.1 Do embedded triples represent a relationship between their subjects and their objects?
>> ------------------------------------------------------------------------------------------
>> In RDF*, an embedded triple is not a real triple. That is, the embedded triple does not create an explicit relationship between its subject and its object. For instance, given the triples [3] and [4] above, the following SPARQL query (meant to gather all available information about :Hamlet) will return empty:
>>
>> ```
>> [15] SELECT ?p ?o WHERE {
>> :Hamlet ?p ?o .
>> }
>> ```
>>
>> Apparently, :Hamlet is the subject of no triples, and, unless the author of the query is committed to exploring in deep the dataset and use the new extension to SPARQL, no information about Hamlet (however uncertain) will ever show up.
>>
>> That might be intentional and well-considered, but we believe it might create misunderstanding and disappointment in end users.
>>
>> In fact, we believe that an actual relationship between :Hamlet and :WilliamShakespeare EXISTS, and that an actual relationship between :Hamlet and :EdwardDeVere ALSO EXISTS. These are NOT authorship relationships, but they are relationships nonetheless. They represent an undeniable connection between :Hamlet, :EdwardDeVere, and :WilliamShakespeare, since someone said something that connects them somehow, and these statements are present in the dataset and that should be returned when searched. I believe that this point of view is more correct and easier to understand than simply returning an empty set.
>>
>> In fact, the exact same query [15], using Conjectures, would return:
>>
>> ```
>> aaa:creator :WilliamShakespeare
>> bbb:creator :EdwardDeVere
>> ```
>>
>> So, asks the puzzled researcher, what are these two predicates I never saw before, aaa:creator and bbb:creator? Well, a slightly more complex query such as
>>
>> ```
>> [16] SELECT ?p1 ?r ?p2 ?o WHERE {
>> :Hamlet ?p1 ?o .
>> OPTIONAL { ?p1 ?r ?p2 }
>> }
>> ```
>>
>> would return the full information about :Hamlet, i.e.:
>>
>> ```
>> aaa:creator conj:isAConjecturalFormOf dc:creator :WilliamShakespeare
>> bbb:creator conj:isAConjecturalFormOf dc:creator :EdwardDeVere
>> ```
>>
>> Reading it in human understandable form: "Hamlet is connected to William Shakespeare through a relation that is a conjectural form of «being created by», and is connected to Edward De Vere through a DIFFERENT relation that is ALSO a conjectural form of "«being created by»". These are interesting statements and are a correct representation of both the dataset and the reality.
>>
>>
>>
>>
>> 4.2 Embed the embedding of a triple / Conjecturing a conjecture
>> ---------------------------------------------------------------
>> Let's go back for a minute to triple [4] above. Suppose I would like to state something more complex, something like
>>
>> "According to article <https://bit.ly/3wSH76A>, :JThomasLooney stated that :Hamlet was written by :EdwardDeVere".
>>
>> Or maybe something even worse:
>>
>> ":FabioVitali mentions that article <https://bit.ly/3wSH76A> reports that :JThomasLooney stated that :Hamlet was written by :EdwardDeVere".
>>
>> These are two, respectively three, nested levels of embedding! In fact, reporting someone else's assertions is a very frequent occurrence in scholarly prose, and constraining provenance to one level only is a narrow and limiting decision.
>>
>> Using RDF*, I would need to embed an embedding, something like:
>>
>> ```
>> [17] <<
>> << :Hamlet dc:creator :EdwardDeVere >>
>> prov:wasAttributedTo :JThomasLooney
>> >>
>> prov:wasInformedBy <https://bit.ly/3wSH76A> .
>> ```
>>
>> and
>>
>> ```
>> [18] <<
>> <<
>> << :Hamlet dc:creator :EdwardDeVere >>
>> prov:wasAttributedTo :JThomasLooney
>> >>
>> prov:wasInformedBy <https://bit.ly/3wSH76A>
>> >>
>> prov:wasAttributedTo :FabioVitali .
>> ```
>>
>> The syntax as specified in 3.2.1 allows such nested statements, but I have yet to see a real case example of it. On the other hand, with Conjectures a solution also exists and it is (in my humble opinion) not particularly cumbersome and used all the time in our reflections and examples:
>>
>> ```
>> [19] CONJECTURE :conjecture02 {
>> :Hamlet dc:creator :EdwardDeVere .
>> }
>> CONJECTURE :conjecture03 {
>> :conjecture02 prov:wasAttributedTo :JThomasLooney .
>> }
>> :conjecture03 prov:wasInformedBy <https://bit.ly/3wSH76A> .
>> ```
>>
>> and
>>
>> ```
>> [20] CONJECTURE :conjecture02 {
>> :Hamlet dc:creator :EdwardDeVere .
>> }
>> CONJECTURE :conjecture03 {
>> :conjecture02 prov:wasAttributedTo :JThomasLooney .
>> }
>> CONJECTURE :conjecture04 {
>> :conjecture03 prov:wasInformedBy <https://bit.ly/3wSH76A> .
>> }
>> :conjecture04 prov:wasAttributedTo :FabioVitali .
>> ```
>>
>>
>>
>>
>> 4.3 Is it possible to embed an annotation? Is it possible to conjecture a collapse?
>> -----------------------------------------------------------------------------------
>> RDF* uses annotations as a short hand for representing triples that are both postulated (embedded) and asserted. As I understand it, annotations are used to suggest that a statement is both postulated AND asserted at the same time (e.g., in your example, ":employee22 said that :employee38 is an Assistant Designer, and in fact :employee38 REALLY IS an Assistant Designer"). In our examples, ":SamuelJohnson said that :Hamlet was written by :WilliamShakespeare, and in fact :Hamlet WAS REALLY WRITTEN by :WilliamShakespeare".
>>
>> So, now, can I postulate an annotation? Is there a way for me to express in RDF* something like "According to the company's bulletin, :employee22 said that :employee38 is an Assistant Designer and they say that in fact this is true." or "According to Encyclopaedia Britannica (https://bit.ly/3qgakFT), :Hamlet was written by :WilliamShakespeare, which correctly :SamuelJohnson stated"?
>>
>> As you see, I am saying something different than an annotation: I am making a new claim, attributed to the company's bulletin, of two statements: a claim by :employee22 and its validation: I am embedding an annotation. Similarly: I am representing a claim, made by Encyclopaedia Britannica, about the authorship of Hamlet and the person who claimed it in the first place: I am recursively embedding not just an embedded triple, but also its corresponding asserted triple as well. I am embedding annotations.
>>
>> In RDF*, embedding annotations does not seem possible. From the syntax in section 3.2.1, production 'annotation' cannot be placed inside an embTriple, and, besides, annotations are shorthands for two separate triples, and embedding only works on individual triples.
>>
>> Yet, in scholarly literature, and especially in highly subjective or unsettled disciplines such as the humanities or history, this pattern is very frequent: whenever debating an unsettled topic, scholars would list several competing claims, along with their provenance, and then assert their trust in one of them, which henceforth would become an asserted statement.
>>
>> This would look something like this:
>> ```
>> [21] <<
>> :employee38 :jobTitle "Assistant Designer" {| :accordingTo :employee22 |} .
>> >>
>> prov:wasInformedBy :companyBulletin .
>> ```
>>
>> or
>>
>> ```
>> [22] <<
>> :Hamlet dc:creator :WilliamShakespeare {| prov:wasAttributedTo :SamuelJohnson |} .
>> >>
>> prov:wasInformedBy <https://bit.ly/3qgakFT>.
>> ```
>>
>> Even if you allow to force this statement into the syntax of RDF*, there would still be problems. Perhaps (I'm making a wild hypothesis here) we can split the annotation in the two triples it is composed of, and embed each of them individually. Thus [21] and [22] could in spirit become:
>>
>> [23] <<
>> << :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
>> >>
>> prov:wasInformedBy :companyBulletin .
>>
>> << :employee38 :jobTitle "Assistant Designer" >> prov:wasInformedBy :companyBulletin .
>>
>> ```
>>
>> and
>>
>> ```
>> [24] <<
>> << :Hamlet dc:creator :WilliamShakespeare>> prov:wasAttributedTo :SamuelJohnson .
>> >>
>> prov:wasInformedBy <https://bit.ly/3qgakFT>.
>>
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasInformedBy <https://bit.ly/3qgakFT>.```
>>
>> Another wild hypothesis would be to use a graph containing the two statements, and embed it, but there is no simple way to embed graphs in the current RDF* syntax.
>>
>> With conjectures, on the other hand, the solution exists and is not particularly difficult to understand:
>>
>> ```
>> [25] CONJECTURE :conjecture05 {
>> :employee38 :jobTitle "Assistant Designer" .
>> }
>> CONJECTURE :collapseOfConjecture05 {
>> :conjecture05 prov:wasAttributedTo :employee22 .
>> :collapseOfConjecture05 conj:collapses :conjecture05 .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy :companyBulletin .
>> ```
>>
>> or
>>
>> ```
>> [26] CONJECTURE :conjecture06 {
>> :Hamlet dc:creator :WilliamShakespeare .
>> }
>> CONJECTURE :collapseOfConjecture06 {
>> :conjecture06 prov:wasAttributedTo :SamuelJohnson .
>> :collapseOfConjecture06 conj:collapses :conjecture06 .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy <https://bit.ly/3qgakFT> .
>> ```
>>
>> As you see :conjecture05 and :conjecture06 are not actually collapsed (asserted), but their assertion of collapse is placed inside another conjecture: the collapse is postulated, not stated.
>>
>> Again, this is not an infrequent need in the scholarly domain.
>>
>>
>>
>>
>>
>> 4.4 Recursive annotations / Cascading collapses
>> -----------------------------------------------
>> Once we start allowing multiple levels of embedding (which, again, is a concrete need and a useful tool), their assertion becomes slightly more complicated. Asserting an embedded triple containing itself an embedding requires recursively asserting the embedded triples up to the first non embedded triple. Consider the previous examples:
>>
>> * "According to the company's bulletin, :employee22 said that :employee38 is an Assistant Designer and they say that in fact this is true."
>> * "According to Encyclopaedia Britannica (https://bit.ly/3qgakFT), :Hamlet was written by :WilliamShakespeare, which correctly :SamuelJohnson stated"
>>
>> If I trust the truth of the company's bulletin, or of Encyclopaedia Britannica, I may want to consider their assertions as true. I'll ignore for the moment that this is not legal syntactically in RDF*, and I'll annotate the embedded triples in [21] and [22] as follows:
>>
>> ```
>> [27] <<
>> :employee38 :jobTitle "Assistant Designer" {| :accordingTo :employee22 |} .
>> >>
>> {| prov:wasInformedBy :companyBulletin |} .
>> ```
>>
>> and
>>
>> ```
>> [28] <<
>> :Hamlet dc:creator :WilliamShakespeare {| prov:wasAttributedTo :SamuelJohnson |} .
>> >>
>> {| prov:wasInformedBy <https://bit.ly/3qgakFT> |}.
>> ```
>>
>> Since annotations are a short hand for the embedded triple plus the annotated triple, this corresponds to:
>>
>> ```
>> [29] <<
>> :employee38 :jobTitle "Assistant Designer" {| :accordingTo :employee22 |} .
>> >>
>> prov:wasInformedBy :companyBulletin .
>>
>> :employee38 :jobTitle "Assistant Designer" {| :accordingTo :employee22 |} .
>> ```
>>
>> and
>>
>> ```
>> [30] <<
>> :Hamlet dc:creator :WilliamShakespeare {| prov:wasAttributedTo :SamuelJohnson |} .
>> >>
>> prov:wasInformedBy <https://bit.ly/3qgakFT>.
>>
>> :Hamlet dc:creator :WilliamShakespeare .
>> ```
>>
>>
>> This first unpackaging has brought to life other annotations, that need to be unwrapped as well:
>>
>> ```
>> [31] <<
>> << :employee38 :jobTitle "Assistant Designer">> :accordingTo :employee22 .
>> :employee38 :jobTitle "Assistant Designer" .
>> >>
>> prov:wasInformedBy :companyBulletin .
>>
>> << :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
>> :employee38 :jobTitle "Assistant Designer" .
>> ```
>>
>> and
>>
>> ```
>> [32] <<
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasAttributedTo :SamuelJohnson .
>> :Hamlet dc:creator :WilliamShakespeare .
>> >>
>> prov:wasInformedBy <https://bit.ly/3qgakFT>.
>>
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasAttributedTo :SamuelJohnson .
>> :Hamlet dc:creator :WilliamShakespeare .
>> ```
>>
>> We have here, again, some unpacking to do, similar to what I did already with [23 and [24], since the embedded "thing" is now composed of two triples and not one. Again: this is not part of the current RDF* syntax, I am just randomly inventing how to extend it. Namely:
>>
>> ```
>> [33] <<
>> << :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
>> >>
>> prov:wasInformedBy :companyBulletin .
>>
>> << :employee38 :jobTitle "Assistant Designer" >> prov:wasInformedBy :companyBulletin .
>> << :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .
>> :employee38 :jobTitle "Assistant Designer" .
>> ```
>>
>> and
>>
>> ```
>> [34] <<
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasAttributedTo :SamuelJohnson .
>> >>
>> prov:wasInformedBy <https://bit.ly/3qgakFT>.
>>
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasInformedBy <https://bit.ly/3qgakFT>.
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasAttributedTo :SamuelJohnson .
>> :Hamlet dc:creator :WilliamShakespeare .
>> ```
>>
>> This complexity is the immediate effect of the cascading nature of trust: if A trusts B and B trusts C, then indirectly A also trusts C. And so on, in cascade, for the statements trusted by C, etc.
>>
>> Let us set aside for a moment that these fragments are hard to read, kind of painful to generate, and not allowed by the current syntax of RDF*. Even in addition to these problems, there is another very important issue that I see: by avoiding to track the origin of the trust, I was forced to generate triples that are not really justified. For instance, the triples:
>>
>> [35] << :employee38 :jobTitle "Assistant Designer" >> prov:wasInformedBy :companyBulletin .
>> << :Hamlet dc:creator :WilliamShakespeare >> prov:wasInformedBy <https://bit.ly/3qgakFT>.
>>
>> lead readers to believe that the company's bulletin asserted the job title of :employee38, and that Encyclopaedia Britannica is an authoritative source for the attribution of Hamlet to Shakespeare, instead of being only intermediaries of the only true authoritative sources, :employee22 and Samuel Johnson. This specific fact does not appear anywhere in the dataset. I think this is wrong and may lead to wrong conclusions.
>>
>> How do conjectures handle such case? I believe they provide a more precise and clean approach. Let's collapse the conjecture of a collapse (items [25] and [26])
>>
>> ```
>> [36] CONJECTURE :conjecture05 {
>> :employee38 :jobTitle "Assistant Designer" .
>> }
>> COLLAPSED CONJECTURE :collapseOfConjecture05 {
>> :conjecture05 prov:wasAttributedTo :employee22 .
>> :collapseOfConjecture05 conj:collapses :conjecture05 .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy :companyBulletin .
>> ```
>>
>> and
>>
>> ```
>> [37] CONJECTURE :conjecture06 {
>> :Hamlet dc:creator :WilliamShakespeare .
>> }
>> COLLAPSED CONJECTURE :collapseOfConjecture06 {
>> :conjecture06 prov:wasAttributedTo :SamuelJohnson .
>> :collapseOfConjecture06 conj:collapses :conjecture06 .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy <https://bit.ly/3qgakFT> .
>> ```
>>
>> Done. Ok, that was just a syntactic trick, I agree.
>>
>> So let's see how it works in plain RDF. Let's first expand items [25] and [26] in plain RDF and see what they become:
>>
>> ```
>> [38] GRAPH :conjecture05 {
>> :employee38 aaa:jobTitle "Assistant Designer" .
>> aaa:jobTitle conj:isAConjecturalFormOf :jobTitle .
>> }
>> GRAPH :collapseOfConjecture05 {
>> :conjecture05 bbb:wasAttributedTo :employee22 .
>> :collapseOfConjecture05 bbb:collapses :conjecture05 .
>>
>> bbb:wasAttributedTo conj:isAConjecturalFormOf prov:wasAttributedTo .
>> bbb:collapses conj:isAConjecturalFormOf conj:collapses .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy :companyBulletin .
>> ```
>>
>> and
>>
>> ```
>> [39] GRAPH :conjecture06 {
>> :Hamlet ccc:creator :WilliamShakespeare .
>> ccc:creator conj:isAConjecturalFormOf dc:creator .
>> }
>> GRAPH :collapseOfConjecture06 {
>> :conjecture06 ddd:wasAttributedTo :SamuelJohnson .
>> :collapseOfConjecture06 ddd:collapses :conjecture06 .
>>
>> ddd:wasAttributedTo conj:isAConjecturalFormOf prov:wasAttributedTo .
>> ddd:collapses conj:isAConjecturalFormOf conj:collapses .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy <https://bit.ly/3qgakFT> .
>> ```
>>
>> Let's now collapse :collapseOfConjecture05 and :collapseOfConjecture06. This requires creating a new graph with all triples of the conjecture except for conj:isAConjecturalFormOf, and reinstating the original predicate for each of them:
>>
>> ```
>> [40] GRAPH :conjecture05 {
>> :employee38 aaa:jobTitle "Assistant Designer" .
>> aaa:jobTitle conj:isAConjecturalFormOf :jobTitle .
>> }
>> GRAPH :collapseOfConjecture05 {
>> :conjecture05 bbb:wasAttributedTo :employee22 .
>> :collapseOfConjecture05 bbb:collapses :conjecture05 .
>>
>> bbb:wasAttributedTo conj:isAConjecturalFormOf prov:wasAttributedTo .
>> bbb:collapses conj:isAConjecturalFormOf conj:collapses .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy :companyBulletin .
>>
>> GRAPH :collapseOfCollapseOfConjecture05 {
>> :conjecture05 prov:wasAttributedTo :employee22 .
>> :collapseOfConjecture05 conj:collapses :conjecture05 .
>>
>> # cascaded triple
>> :employee38 :jobTitle "Assistant Designer" .
>> }
>> ```
>>
>> and
>>
>> ```
>> [41] GRAPH :conjecture06 {
>> :Hamlet ccc:creator :WilliamShakespeare .
>> ccc:creator conj:isAConjecturalFormOf dc:creator .
>> }
>> GRAPH :collapseOfConjecture06 {
>> :conjecture06 ddd:wasAttributedTo :SamuelJohnson .
>> :collapseOfConjecture06 ddd:collapses :conjecture06 .
>>
>> ddd:wasAttributedTo conj:isAConjecturalFormOf prov:wasAttributedTo .
>> ddd:collapses conj:isAConjecturalFormOf conj:collapses .
>> }
>> :collapseOfConjecture05 prov:wasInformedBy <https://bit.ly/3qgakFT> .
>>
>> GRAPH :collapseOfCollapseOfConjecture06 {
>> :conjecture06 prov:wasAttributedTo :SamuelJohnson .
>> :collapseOfConjecture06 conj:collapses :conjecture06 .
>>
>> # cascaded triple
>> :Hamlet dc:creator :WilliamShakespeare .
>> }
>> ```
>>
>> As you can see, one of the predicates being asserted was conj:collapses. This means that we need to collapse the corresponding graphs, too, and therefore asserting all conjectural triples contained therein (:employee38 :jobTitle "Assistant Designer" and :Hamlet dc:creator :WilliamShakespeare) .
>>
>> With this approach, all true statements have been re-established and no spurious and unjustified statement has been added (such as [35] ).
>>
>> The overall result is (at least to me) clearer to the eye and more precise.
>>
>>
>>
>>
>>
>>
>>
>> 5 Some real life examples of the need of conjectures and how to use them
>> ========================================================================
>>
>> In addition to the concocted example of Shakespeare and Hamlet, invented just for the sake of the illustration of the proposal, we routinely deal everyday with examples where RDF* and conjectures would be useful. Let me give you a few examples:
>>
>> 5.1 Posthumous Diary
>> --------------------
>> Eugenio Montale, the 1975 Nobel Prize laureate in Literature, died in 1981. In 1986, his executor, friend and lover Annalisa Cima, also a poet on her own, announced that just before his death he gave her 11 envelopes, each containing several unpublished poems (84 overall) and instructed her to open and publish one envelope every year for 11 years starting five years after his death. These poems were later published as a single volume under the name "Diario Postumo".
>>
>> Pretty soon a number of oddities were identified by scholars: the handwriting was barely intelligible and quite dissimilar to established autographs, the poetic style was not similar to that of any specific temporal interval of his career but rather looked like a sort of mashup of styles and word choices of fairly different eras, including some peculiarities of Annalisa Cima's own style, and each and every poem was an eulogy of either Annalisa Cima or of someone of her own inner circle. The debate was harsh and widespread, starting in 1997, slowing down in 1999, and rehashed between 2014 and 2019 due to renewed interests and quarrelling between some scholars and Cima herself. In September 2019, Annalisa Cima died taking to her grave the full story behind this work.
>>
>> The scholar Federico Condello provides a fairly detailed summary of the querelle, casting well-documented doubts about the actual authorship of this work. Condello does not explicitly attribute Posthumous Diary to Annalisa Cima, but, by reading between the lines, one can gather a clear impression that this is his true opinion.
>>
>> In our example we want to express the following facts:
>>
>> 1 Annalisa Cima asserts that the work "Posthumous diary" was created by Eugenio Montale.
>> 2 Fabio Vitali asserts that Condello implies that the work "Posthumous diary" was created by Annalisa Cima.
>> 3 Fabio Vitali agrees with Federico Condello's attribution.
>> 4 We trust Fabio Vitali.
>> 5 Please note that we are NOT allowed to say that Federico Condello asserts that the work "Posthumous diary" was created by Annalisa Cima.
>> ```
>> [42] @prefix : <http://www.example.org/exampleDocument/> .
>> @prefix prov: <http://www.w3.org/ns/prov-o/> .
>> @prefix dc: <http://purl.org/dc/elements/1.1/> .
>> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>> @prefix frbr: <http://purl.org/spar/frbr/> .
>> @prefix conj: <http://conjectures.altervista.org/1.0/> .
>>
>> :PosthumousDiary a frbr:Work .
>> :EugenioMontale a foaf:Person .
>> :AnnalisaCima a foaf:Person .
>> :FedericoCondello a foaf:Person .
>> :FabioVitali a foaf:Person .
>>
>> CONJECTURE :attribution1 {
>> :PosthumousDiary dc:creator :EugenioMontale .
>> }
>> :attribution1 prov:wasAttributedTo :AnnalisaCima .
>>
>> CONJECTURE :attribution2 {
>> :PosthumousDiary dc:creator :AnnalisaCima .
>> }
>>
>> COLLAPSED CONJECTURE :attribution3 {
>> :attribution2 prov:wasAttributedTo :FedericoCondello .
>> :attribution3 conj:collapses :attribution2 .
>> }
>> :attribution3 prov:wasAttributedTo :FabioVitali .
>> ```
>>
>> This is converted into the following plain RDF representation:
>>
>> ```
>> [43] @prefix : <http://www.example.org/exampleDocument/> .
>> @prefix prov: <http://www.w3.org/ns/prov-o/> .
>> @prefix dc: <http://purl.org/dc/elements/1.1/> .
>> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>> @prefix frbr: <http://purl.org/spar/frbr/> .
>> @prefix conj: <http://conjectures.altervista.org/1.0/> .
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>> @prefix conj1: <http://www.example.org/exampleDocument/attribution1/> .
>> @prefix conj2: <http://www.example.org/exampleDocument/attribution2/> .
>> @prefix conj3: <http://www.example.org/exampleDocument/attribution3/> .
>>
>> :PosthumousDiary rdfs:type frbr:Work .
>> :EugenioMontale rdfs:type foaf:Person .
>> :AnnalisaCima rdfs:type foaf:Person .
>> :FedericoCondello rdfs:type foaf:Person .
>> :FabioVitali rdfs:type foaf:Person .
>>
>> GRAPH :attribution1 {
>> :PosthumousDiary conj1:creator :EugenioMontale .
>> conj1:creator conj:isConjecturallyEquivalentTo dc:creator .
>> }
>> :attribution1 prov:wasAttributedTo :AnnalisaCima .
>>
>> GRAPH :attribution2 {
>> :PosthumousDiary conj2:creator :AnnalisaCima .
>> conj2:creator conj:isConjecturallyEquivalentTo dc:creator .
>> }
>>
>> GRAPH :attribution3 {
>> :attribution2 conj3:wasAttributedTo :FedericoCondello .
>> :attribution3 conj3:collapses :attribution2 .
>> conj3:wasAttributedTo conj:isConjecturallyEquivalentTo prov:wasAttributedTo .
>> conj3:collapses conj:isConjecturallyEquivalentTo conj:collapses .
>> }
>> :attribution3 prov:wasAttributedTo :FabioVitali .
>>
>> GRAPH :collapseOfattribution3 {
>> :collapseOfattribution3 conj:collapses :attribution3 .
>> :attribution2 prov:wasAttributedTo :FedericoCondello .
>> :attribution3 conj:collapses :attribution2 .
>>
>> # cascaded triple
>> :PosthumousDiary dc:creator :AnnalisaCima
>> }
>> ```
>>
>> 5.2 Attribution of "Le tre grazie" according to Christie's and Federico Zeri
>> ----------------------------------------------------------------------------
>>
>> In 1974, a XV-XVI Century artwork, a detached fresco known as "Le tre grazie" (the Three Graces) was put up for auction at Christie's as a work from the school of Bernardino Luini (1480-1532). Art expert Federico Zeri, basing his judgment on a rich bibliography of scholarly and art experts writings throughout the centuries, later proposed a different attribution to Baldassarre Peruzzi (1481-1536). This is the accepted attribution at the Federico Zeri Foundation. The item is now on display in a private gallery in Rome with Federico Zeri's attribution, and after having been restored with the removal of vegetal elements and of the veil covering the bodies of the Graces. Check it at https://dicastro.com/wp-content/uploads/2020/11/Tre-Grazie.pdf
>>
>> This could be a Conjecture-based representation:
>> ```
>> [44] @prefix cito: <http://purl.org/spar/cito/> .
>> @prefix crm: <http://www.cidoc-crm.org/cidoc-crm/> .
>> @prefix fabio: <http://purl.org/spar/fabio/> .
>> @prefix hico: <http://purl.org/emmedi/hico/> .
>> @prefix prov: <http://www.w3.org/ns/prov#> .
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>>
>> <https://w3id.org/zericatalog/artwork/39794> a fabio:ArtisticWork ;
>> rdfs:label "Artwork 'Tre Grazie'" .
>>
>> # Attribution to Peruzzi
>> CONJECTURE <https://w3id.org/zericatalog/conjecture/975234> {
>> <https://w3id.org/zericatalog/artwork/39794/creation> a crm:E65_Creation ;
>> rdfs:label "Creation of the artwork 'Tre Grazie', 1500-1535 by Baldassarre Peruzzi" ;
>> crm:P94_has_created <https://w3id.org/zericatalog/artwork/39794> ;
>> crm:P14_carried_out_by <https://w3id.org/zericatalog/person/8084/peruzzi-baldassarre> ;
>> crm:P4_has_time_span <https://w3id.org/zericatalog/date/1500-1535> .
>> }
>> <https://w3id.org/zericatalog/conjecture/975234> prov:wasGeneratedBy <https://w3id.org/zericatalog/artwork/39794/authorship/peruzzi-baldassarre> .
>>
>> # Attribution accepted by Federico Zeri
>> COLLAPSED CONJECTURE <https://w3id.org/zericatalog/conjecture/975235> {
>> <https://w3id.org/zericatalog/artwork/39794/authorship/peruzzi-baldassarre> a hico:InterpretationAct ;
>> crm:P3_has_note "Bibliografia" ;
>> rdfs:label "Authorship attribution of the artistic work: Peruzzi Baldassarre" ;
>> hico:hasInterpretationType <https://w3id.org/zericatalog/type-of-attribution/zeri-preferred-attribution> ;
>> prov:wasAssociatedWith <https://w3id.org/zericatalog/organization/crr-mm> ;
>> hico:isExtractedFrom <https://w3id.org/zericatalog/oaentry/37495/expression-1>.
>> <https://w3id.org/zericatalog/conjecture/975235> conj:collapses <https://w3id.org/zericatalog/conjecture/975234>.
>> }
>>
>> # Attribution to Luini's school
>> CONJECTURE <https://w3id.org/zericatalog/conjecture/975236> {
>> <https://w3id.org/zericatalog/artwork/39794/creation/1> a crm:E65_Creation ;
>> rdfs:label "Creation of the artistic work 'Tre Grazie' by Luini Bernardino's school" ;
>> crm:P94_has_created <https://w3id.org/zericatalog/artwork/39794> ;
>> crm:P14_carried_out_by <https://w3id.org/zericatalog/luini-bernardino/s-school> .
>> }
>> <https://w3id.org/zericatalog/conjecture/975236> prov:wasGeneratedBy <https://w3id.org/zericatalog/artwork/39794/authorship/luini-bernardino/s-school>.
>>
>>
>> # Attribution by Christie's catalog (1994)
>> CONJECTURE <https://w3id.org/zericatalog/conjecture/975237> {
>> <https://w3id.org/zericatalog/artwork/39794/authorship/luini-bernardino/s-school>
>> a hico:InterpretationAct ;
>> crm:P3_has_note "Asta Christie's (1994)" ;
>> rdfs:label "Authorship attribution of the artistic work: Luini Bernardino, scuola " ;
>> hico:hasInterpretationType <https://w3id.org/zericatalog/type-of-attribution/zeri-discarded-attribution> ;
>> prov:wasAssociatedWith <https://w3id.org/zericatalog/organization/crr-mm> ;
>> hico:isExtractedFrom <https://w3id.org/zericatalog/oaentry/37495/expression-1> ;
>> cito:disagreesWith <https://w3id.org/zericatalog/artwork/39794/authorship/peruzzi-baldassarre>.
>> <https://w3id.org/zericatalog/conjecture/975237> conj:collapses <https://w3id.org/zericatalog/conjecture/975236>.
>> }
>> ```
>>
>> 5.3 Nanopublications for discredited scholarly assertions
>> ---------------------------------------------------------
>> Scientific publishing is the means by which we communicate and share scientific knowledge, but this process currently often lacks transparency and machine-interpretable representations. A nanopublication consists of an RDF-based representation of the smallest-grained assertions of a scientific discourse. A good nanopublication is composed of an assertion, the provenance of the assertion (simply called "provenance"), and the provenance of the whole nanopublication (called "publication info"). These three parts are represented as RDF graphs, and are glued together by a "head" that explicitly connects these three graphs.
>>
>> The current problem of nanopublications is that it assumes that we believe and trust the assertion of the publication. In fact, all examples I could put my hands on were of trivially true or totally acceptable facts.
>>
>> Since the assertion part in nanopublications is a plain graph, and in RDF the truth of the content of a graph is unspecified and therefore is often considered as automatically stated, we have a problem if we want to use nanopublications to express wrong, debated or discredited scholarly assertions.
>>
>> I will make here a rather extreme example: in 1650, James Ussher (1581-1656), Archibishop of Armagh (Ireland), published his most famous work "Annales Veteris Testamenti, a prima mundi origine deducti, una cum rerum Asiaticarum et Aegyptiacarum chronico, a temporis historici principio usque ad Maccabaicorum initia producto" ("Annals of the Old Testament, deduced from the first origins of the world, the chronicle of Asiatic and Egyptian matters together produced from the beginning of historical time up to the beginnings of Maccabees"). In this work, Ussher brings forth the assertions, based on intricate computations on the dates found in the King James Bible, that the Earth was created on October 23rd, 4004 BC.
>>
>> Ussher's Annales is a scholarly work of great erudition, ample reverberation and long-standing impact, and although its findings have no appeal in current day's scholarly communities, they certainly belong to the scholarly debate, and I trust you agree with me that his assertions should be expressible as nanopublications. I will use wikidata's predicates for Ussher's statements:
>>
>> ```
>> [45] @prefix : <http://www.example.com/Ussher/> .
>> @prefix np: <http://www.nanopub.org/nschema#> .
>> @prefix wd: <http://www.wikidata.org/entity/> .
>> @prefix wdt: <http://www.wikidata.org/prop/direct/> .
>> @prefix prov: <http://www.w3.org/ns/prov#> .
>> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>> @prefix fabio: <http://purl.org/spar/fabio/> .
>>
>> :assertion {
>> # Earth inception date is 23rd October 4004 b.C.
>> # Q2 = Earth
>> # P571 = inception date
>> wd:Q2 wdt:P571 "-4004-10-23"^^xsd:date .
>> }
>>
>> :provenance {
>> # Q333481 = James Ussher
>> :assertion prov:wasAttributedTo wd:Q333481 .
>> :assertion prov:hadPrimarySource :AnnalesVeterisTestamenti .
>> :AnnalesVeterisTestamenti a fabio:Work .
>> }
>>
>> :pubInfo {
>> : prov:hadPrimarySource <https://en.wikipedia.org/wiki/Ussher_chronology> .
>> : prov:atTime "2021-06-18T15:59:22"^^xsd:dateTime .
>> }
>>
>> :Head {
>> : a np:Nanopublication .
>> : np:hasAssertion :assertion .
>> : np:hasProvenance :provenance .
>> : np:hasPublicationInfo :pubInfo .
>> }
>> ```
>> With a plain nanopublication, the content of the :assertion graph is NOT shielded in any way: I not only stated that Ussher said that the Earth was created in 4004 b.C., I also stated that the Earth was in fact created in 4004 b.C.. Yet, I do not like to be known as a living scholar asserting these things.
>>
>> By simply adding the "CONJECTURE" keyword in front of the assertion part I can transform a statement (especially one I disagree with) from an assertion into a simple reported statement, with no assertion involved: Ussher's dating is now defused and can be easily discussed without fearing that some may take it for true.
>>
>> ```
>> [46] @prefix : <http://www.example.com/Ussher/> .
>> @prefix np: <http://www.nanopub.org/nschema#> .
>> @prefix wd: <http://www.wikidata.org/entity/> .
>> @prefix wdt: <http://www.wikidata.org/prop/direct/> .
>> @prefix prov: <http://www.w3.org/ns/prov#> .
>> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>> @prefix fabio: <http://purl.org/spar/fabio/> .
>>
>> CONJECTURE :assertion {
>> # Earth inception date is 23rd October 4004 b.C.
>> # Q2 = Earth
>> # P571 = inception date
>> wd:Q2 wdt:P571 "-4004-10-23"^^xsd:date .
>> }
>>
>> :provenance {
>> # Q333481 = James Ussher
>> :assertion prov:wasAttributedTo wd:Q333481 .
>> :assertion prov:hadPrimarySource :AnnalesVeterisTestamenti .
>> :AnnalesVeterisTestamenti a fabio:Work .
>> }
>>
>> :pubInfo {
>> : prov:hadPrimarySource <https://en.wikipedia.org/wiki/Ussher_chronology> .
>> : prov:atTime "2021-06-18T15:59:22"^^xsd:dateTime .
>> }
>>
>> :Head {
>> : a np:Nanopublication .
>> : np:hasAssertion :assertion .
>> : np:hasProvenance :provenance .
>> : np:hasPublicationInfo :pubInfo .
>> }
>> ```
>>
>> Please notice that since RDF* deals with individual triples, and nanopublications use graphs, the postulation of the assertions of a nanopublication would be problematic with RDF* alone, since I would need to postulate each individual triple.
>>
>>
>>
>> 6 Integrating RDF* and conjectures
>> ==================================
>>
>> Nothing would make me happier than finding a way for the best parts of RDF* and Conjectures (Conj) to be integrated into a single and stronger proposal. In fact I find the two proposals interestingly complementary.
>>
>> * RDF*'s main focus is on providing an identity to individual triples to be used as subjects or objects of other triples.
>> * Conj's main focus is on expressing statements without asserting them.
>>
>> * RDF* was not meant to and does not work with graphs.
>> * Conj is oriented towards graphs and does not have a direct way to work with individual triples.
>>
>> * In RDF* the non-assertion of individual triples is a side effect of its reification (since it does not use rdf:-based reification).
>> * Conj does not rely on any kind of reification, but uses freshly minted predicates to connect the same subjects and the same objects.
>>
>> * RDF* does not directly support triples that are both expressed (embedded) and asserted, but provides a syntactical shorthand for this specific case, called annotations.
>> * Conj explicitly supports graphs that are both expressed and asserted (the collapse of a conjecture).
>>
>> * The syntax of RDF* allows the embedding of embedding (but it's nowhere mentioned in the prose)
>> * Conj allows conjectures of conjectures (and it has a rich set of use cases for it)
>>
>> * The syntax of RDF* does not allow the embedding of annotations
>> * Conj allows conjectures of collapses (and it has a rich set of use cases for it)
>>
>> * RDF* does not deal with cascading assertions of embedded triples (since it does not allow embedded annotations)
>> * Conj has a specific set of rules for dealing with cascading collapses
>>
>> * RDF* does not connect in any way the subject and objects involved in an embedded triple
>> * Conj uses a freshly minted predicate specifically to express a connection between the subject and the object of the non-asserted triples. These are easy to find with SPARQL and impossible to mistake for the real ones.
>>
>> I truly believe that a merge of the two proposal could enhance and strengthen considerably the expressive power of RDF*, and that the effort for this merge could be somehow restricted to just a few productions inside section 2.4 of 6.1 in the current draft.
>>
>> I'll be glad to further illustrate my point.
>>
>> The gist of my proposal is:
>> a) to make sure that a symmetry exists between expressing without asserting individual triples (aka embedding) and expressing whole graphs (aka conjecturing).
>> b) to allow easy querability of statements expressed but not asserted
>> c) to promote annotations to first-class entities, so that they can be mentioned, addressed, embedded, asserted, and even annotated.
>>
>> For items a) and b) I am proposing two very simple modifications to section 6.1 of the current draft:
>> 2.5) Mint a new and unique predicate (different from all other predicates present and future) np
>> 2.6) Add two additional triples to G:
>> * (s, np, o)
>> * (np, unstar:isAConjecturalFormOf, p) ## or isAWeakFormOf or isAHypotheticalFormOf or anything you fancy.
>>
>> Basically, this is equivalent to adding a new relationship between the subject and the object, that creates a queriable connection between them without being the original predicate (that remains unasserted), and then assessing a connection of some kind between the original predicate and the newly minted one.
>>
>>
>>
>> Regarding item c), on the other hand, there are two possible paths. In fact, an annotation is intrinsically two different things that happen at the same time, the embedded and the asserted triple. It makes little sense to assign special properties to the asserted triple, as it would require embedding it, and looping back to the problem of asserting it.
>>
>> Therefore there are two ways:
>>
>> Method A: In case of annotations, add the basic triple as well as yet another triple to G, as follows:
>> A - 2.7 For each annotation A = " s p1 o1 {| p2 o2 |} ", let assume s, p1, o1, p2, o2 are its constituents. Then
>> * mint triple (s, p1, o1)
>> * mint the appropriate blank node b as specified in 2.1 - 2.6 for the RDF-star graph << s, p1, o1 >>
>> * mint triple (b, p2, o2)
>> * mint triple (b, unstar:isAsserted, true^^xsd:boolean)
>>
>> Basically, this is equivalent to expressing separately the embedded triple and its assertion, and then adding a single "isAsserted" boolean value over the blank node of the embedding. The good of it is that this is a very simple solution with very little overhead (just ONE additional triple) but the bad part is that still there is no explicit connection between the asserted triple and the embedded one, and that extending this to graphs may become complicated.
>>
>> Method B: Exploit the multiplicity of annotations and wrap them inside a graph, as follows:
>> B - 2.7 For each annotation A = " s p1 o1 {| p2 o2 |} ", let assume s, p1, o1, p2, o2 are its constituents. Then
>> * mint the appropriate blank node b as specified in 2.1 - 2.6 for RDF-star graph << s, p1, o1 >>
>> * mint triple (b, p2, o2)
>> * mint graph g
>> * place triple (s, p1, o1) inside g
>> * place triple (g, unstar:asserts, b ) inside g ## or collapses or annotates or anything you fancy.
>>
>> Basically, this is equivalent to grouping together the triple as asserted and the relationship of such assertion and its embedded form. The good of it is that this is still a rather simple solution that is compatible with the graph-oriented approach used by Conjectures, but the bad part is that it relies on graphs and therefore on RDF 1.1.
>>
>>
>>
>>
>> 7 Conclusions
>> =============
>>
>> All in all, the modifications to the RDF* proposal would be extremely limited, and the number of additional advantages would be striking:
>> 1 maintain main focus and main line of approach of the current RDF* draft;
>> 1 create a symmetry between expressing without asserting triples and graphs;
>> 2 support a trivial querability of embedded triples and graphs
>> 3 provide an identification means for annotations
>> 4 allow the embedding of annotations
>> 5 allow annotations over the embedding of annotations, and the cascade of annotations and embeddings
>>
>> I am more than willing to expose this proposal and discuss it at whatever level you feel appropriate. Also, I have an analogous proposal (and just as simple) to extend Sparql to handle conjectures, but I felt it was out of scope of this already too-long message.
>>
>> In the meantime let me attach a draft of the formal model of conjectures in the current stage of formalization. Also please feel free to test the current Conjecture-oriented extensions to Trig (called Trick) and to SPARQL (called Con-SPARQL) at http://conjectures.altervista.org/.
>>
>> Best regards
>>
>> Fabio Vitali
>> (with Alessio Rolfini)
>>
>> --
>>
>> Fabio Vitali Tiger got to hunt, bird got to fly,
>> Dept. of Computer Science Man got to sit and wonder "Why, why, why?'
>> Univ. of Bologna ITALY Tiger got to sleep, bird got to land,
>> phone: +39 051 2094872 Man got to tell himself he understand.
>> e-mail: fabio@cs.unibo.it Kurt Vonnegut (1922-2007), "Cat's cradle"
>> http://vitali.web.cs.unibo.it/
>>
>>
>>
> <OpenPGP_0x9D1EDAEEEF98D438.asc>
Received on Friday, 17 September 2021 14:34:45 UTC