Re: RDF* and conjectures

Dear Pierre-Antoine, all, 

I do not want to insist too much. 

It is complicated to enter in a new group of unknown highly competent people with a proposal, as at the same time one has to justify one's own competence, justify the need for their proposal, justify the feasibility of their proposal, and not cross or bore too many people. This is a difficult task and I am not known, in general, for succeeding in all of them at the same time. 

So allow me a last round of responses, and then I will subdue in the background until (and if) the group's consensus will grow in the direction of discussing one or more of the five items I listed in [1] and repeated in the following. 

--

The semantics of plain RDF already had the possibility to 
1) express stated triples directly (s p o), 
2) reify triples that are stated (through rdf:Statement), and 
3) reify triples that are not intended as stated (through a custom vocabulary, e.g., myown:Statement). 

RDF* decided to provide a convenience syntax for 3, reification of unstated triples, something that was 100% already and precisely expressible in RDF. The intent here is to simplify the life of users and homogenise all possible approaches into a single one. 

A similar syntax is lacking with named graph, with the additional burden that, differently from triples, the actual semantics of named graph is undetermined and open to different local interpretations, and there is no clear way to distinguish the corresponding item 3 from item 2. 

***
Conjectures simply aims at suggesting a convenience syntax for reification of unstated named graphs, with the clear intent to simplify the life of users and homogenise all possible approaches into a single one. 
***


To me the similarity and parallelism is clear, but maybe I am alone. 


--
Anyway, here I am not proposing that RDF* adopt conjectures. I am simply volunteering to participate in any discussion about any of these topics if and when the group will feel the need to consider them:   

(*)
1) promote annotations to first class citizens of the model
2) extend the reach from a convenience syntax for postulated triples to a convenience syntax for postulated graphs
3) include mechanisms to postulate the postulation of triples/graphs (already doable)
4) include mechanisms to postulate the assertion of postulated triples/graphs 
5) work with the cascade effect of asserting chained postulations

If and when this will happen, I will be glad to contribute. 

--

In the meantime, please do not consider my messages as requests or solicitations to get these topics on the table. 

Thank you

Fabio Vitali

[1]

> On 17 Sep 2021, at 13:52, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
> 
> To clarify my position:
> 
> the semantics of datasets / named graphs is not governed by the RDF standard.
> 
> The bad thing about it is that two implementations will behave differently with the same TriG file.
> 
> The good thing about it is that you are free to define your own semantics and implement it (from scratch, or based on some implementation whose behaviour is compatible with it). That's what nanopublications are doing.
> 
> So you are free to define your own semantics for named graphs in which they behave as conjectures, where some of them are asserted and others are not. In this setting, I don't see any need to extend the TriG syntax.
> 
>     GRAPH :conjecture01 { 
>         :Hamlet dc:creator :WilliamShakespeare . 
>     } 
>     :conjecture01 a conj:CollapsedConjecture ;
>         prov:wasAttributedTo :SamuelJohnson . 
>  
>     GRAPH :conjecture02 { 
>         :Hamlet dc:creator :EdwardDeVere . 
>     } 
>     :conjecture02 a conj:Conjecture ;
>         prov:wasAttributedTo :JThomasLooney .
> 
> In another thread [1] you make a parallel with how RDF-star's semantics is defined, i.e. through a rewriting to standard RDF.  I see this as a completely different situation: the sole purpose of this renaming is to use the standard RDF semantics as the       foundation of RDF-star's semantics . In your case, RDF datasets have no standard semantics to build on, so the rewriting seems unnecessary.
> 
>   pa
> 
> [1] https://www.w3.org/mid/FE5A611B-B622-4948-AA02-8B8455E18EB6@unibo.it
> 
> 
> 
> On 17/09/2021 10:43, Fabio Vitali wrote:
>> Dear Pierre-Antoine, 
>> 
>> thank you first of all for all the time and energy you spent on our proposal. 
>> 
>> 
>>> From what you wrote, it seems to stem from the misconception that named graphs are asserted, which they are not.
>>> 
>> Thank you. This bears providing some explanations, which I naively skipped over in my first document. 
>> 
>> The reading of [1] brings us to the conclusion that we DO NOT KNOW if named graphs are asserted. In fact, of the seven different (and reciprocally incompatible) semantics represented in [1], only one (3.4) behaves as if the content of the named graph is not asserted. As far as I can see, all the others do not explicitly rule out the assertion of its content. In addition, it is said: "The RDF Working Group did not define a formal semantics for a multiple graph data model because none of the semantics presented before could obtained consensus. Choosing one or another of the propositions before would have gone against some deployed implementations."
>> 
>> So there is no clear standing point, wrt plain named graph, that can justify the idea that the content of named graphs is not asserted: depending on your point of view or standing point, they might or might not. 
>> 
>> In addition, the whole justification of conjecture is NOT to make unasserted graphs, but to have within the same dataset BOTH unasserted and asserted graphs, and to be able to distinguish which is which. Whatever semantics ends up being chosen of the seven proposed in [1], there will be no semantics for the opposite case, and I would like to be able to express both. 
>> 
>> There are situations in which some graphs should be considered as asserted and other as only postulated. With plain RDF, these two graphs:
>> 
>> GRAPH :conjecture01 {
>>     :Hamlet dc:creator :WilliamShakespeare .
>>     :Hamlet dc:created "1603"^^xsd:Year .
>> }
>> :conjecture01 prov:wasAttributedTo :SamuelJohnson .
>> 
>> GRAPH :conjecture02 {
>>     :Hamlet dc:creator :EdwardDeVere .
>>     :Hamlet dc:created "1596"^^xsd:Year .
>> }
>> :conjecture02 prov:wasAttributedTo :JThomasLooney .
>> 
>> are either BOTH asserted or BOTH non asserted. Is there a way to distinguish the two situations? Well, in this case we could simply repeat outside of the graph the statements we wish to assert, true. 
>> 
>> But sometimes (e.g., with nanopublications) I am expected to use graphs. Consider for instance the nanopublication about Ussher's chronology of the Earth that I mentioned in my first message [2]: 
>> 
>> 	: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 .
>> 	}
>> 
>> The requirements for nanopublications ask me to use four named graphs. Of these four, three are non problematic: :Head, :pubInfo and :provenance simply state objective facts about who, where and how did we gather the information about :assertion. The problem here is with graph :assertion, which contains statements that Ussher thought true, and we should not (namely, that Earth was created on the 23rd of October of 4004 b.C.) 
>> 
>> You cannot have it both ways: with standard named graphs, either all of them are not asserted, or they all are. 
>> 
>> In conclusion, whatever semantics you choose for named graphs, it only satisfies one of the two necessary semantics, and yet we need TWO separate constructs for expressing both. These two constructs have not been forwarded, and therefore we must do with what we have. Overall, I believe that it is safer to assume that plain named graphs MIGHT be considered asserted, and therefore propose to introduce a mechanism that clearly and unambiguously MUST NOT be considered asserted. 
>> 
>> More answers to come on your other message. 
>> 
>> Thank you again for your time
>> 
>> 
>> Fabio
>> 
>> --
>> 
>> [1] 
>> https://www.w3.org/TR/rdf11-datasets/
>> 
>> 
>> 
>> 
>>> 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.
>>> 
>>>   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:
>>> ...
>>> 
>> 
> <OpenPGP_0x9D1EDAEEEF98D438.asc>

Received on Friday, 17 September 2021 13:41:08 UTC