Re: RDF-star Agenda for 2021-09-17

Dear Pierre-Antoine, all the others. 

>> I am wondering, specifically, if the fact that quoted triples are postulated but not asserted came out as a pleasant side effect of the peculiar type of reification adopted for the formal model of RDF* triples, or if this feature was (is, will be) considered as a true design goal for the group, and if there are plan to explore this specific subtree of additional features.
>> 
> This is not a mere side effect, but the outcome of long discussions which we tried to summarized in an appendix the spec [1].

Thank you. I do not want to imply that the decision to adopt SA-mode did not come lightly nor without a deep understanding of the impacts. 

I totally agree that SA-mode is a more elegant approach to RDF* triples that PG-mode, and in fact I wholly support it, so much so, that I would appreciate if the concept of Postulating Without Asserting (PWA) would be explorer further. 

>>  If this is the case, then I am wondering if there is an interest in discussing sooner or later about the following: 
>> 
>> 1) promote annotations to first class citizens of the model, and not just leaving them as syntactic shortcuts
>> 
> this seems to relate to something else you wrote in your previous e-mail: "annotations are shorthands for two separate triples".
> 
> First, let me point out a difference in terminology which might foster misunderstanding in this discussion. IIUC, what you call an annotation is statement about a conjecture. In RDF-star, an annotation is a statement about an asserted triple (a "collapsed conjecture" in your terminology, I believe -- leaving aside the fact that your conjectures can have multiple triples).
> 
> So in RDF-star:
> 
>   << :hamlet dc:creator :shakespeare >> :statedBy :johnson.
> 
> is not called an annotation.  It is simply a nested triple (i.e. a triple containing another triple). And to answer your point above: this thing is a first class citizen in RDF-star.

Indeed. A nested triple is a first class citizen in RDF-star. On the other hand, as I wrote, *annotations* are NOT first class citizens. 

To clarify further: 

Quoted triple (used to be called embedded triple): 
	<< :hamlet dc:creator :shakespeare >> :statedBy :johnson.

Asserted triple
	:hamlet dc:creator :shakespeare .

Annotation: 
	:hamlet dc:creator :shakespeare {| :statedBy :johnson |}.

While quoted triples have an official standing in the semantics (e.g. all of 6.1 in [1]), annotations do not. They appear in the grammar in 3.1.1 in a single position and described in text as a shorthand for two separate triples: 

	<< :hamlet dc:creator :shakespeare >> :statedBy :johnson.
	:hamlet dc:creator :shakespeare .

I believe annotations deserve a greater role in the proposal and doing so would open a few easy roads towards very interesting features. 

> Second, if I was now to assert the fact that Shakespeare wrote Hamlet, I would now have two triples:
> 
>   :hamlet dc:creator :shakespeare. 
>   << :hamlet dc:creator :shakespeare >> :statedBy :johnson.
> 
> and you wrote in your previous e-mail "there is no specific relationship between the two triples". I would argue the contrary: it is important to remember that the triple ':hamlet dc:creator :shakespeare' is one and the same thing everywhere it occurs (either asserted or embedded). So the two triples above are as strongly related as, for example, the two triples below:
> 
>   :hamlet rdf:type :Play.
>   :hamlet dc:creator :shakespeare.

Ehm. Yes and no. The mere fact that we are about to discuss the need to provide quoted triples with an URI [2] implies that we are understanding that "Having a URI for quoted triples is a "must" for me. There is a proposal as part of #169 that covers this and more."

In fact, in issue #169 [3] I find: "After long debate it was decided that embedded triples refer to an ("abstract") triple, not to any specific occurrence. Use cases like the seminal provenance use case [0] however need to refer to a specific occurrence to document e.g. when a certain triple was inserted into a certain graph. "

The idea that a specific occurrence of a triple may need to be identified clearly resonates with this need. 

>> 2) extend the reach from postulated triples to postulated graphs
> If we did this, RDF-star would have little benefit compared to named-graphs (which are already part of RDF). Actually, some people have argued that RDF-star is not required, as it can be "emulated" using named graphs.

As my previous messages were meant to convey, I do not believe that named graphs already have in themselves this feature fully formed and available. 


I do not want to start again the discussion, but whatever is your opinion on this, one thing I think is clear: 

****************

Postulating Without Asserting triples is intrinsically different than Postulating Without Asserting named graphs, and maybe a convergent approach could be appropriate. 

****************


> Another way to answer this is (as Andy already did [2]) is that you can use RDF-star as a building block to address this use-case:
> 
> [ a :Conjecture
>   :contains
>     << :hamlet dc:creator :shakespeare >>,
>     << :hamlet dc:created "1603"^^xsd:gYear >>
> ] :source <https://en.wikipedia.org/wiki/Hamlet>. 

Damn! I completely missed Andy's mail. I shall respond to that straight away. 

Your example is cool, but I am not sure how I could use this in a context in which I am expected to use a graph, as in nanopublications. The following:  

	:assertion {
	  wd:Q2 wdt:P571 "-4004-10-23"^^xsd:date .
	}
	:assertion a :Conjecture

still asserts (or not) the content of the graph. 

>> 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
>> 
> I have to think more about what the last two points would mean for RDF-star, but my gut feeling is that this could be built on top of it using a dedicated vocabulary (with a specified semantics).

I am not sure how to interpret this. 

In a way, this is exactly what Conjectures do: we have created a new syntax, and expressed it as plain RDF using a dedicated vocabulary of exactly two new properties, conj:isAConjecturalFormOf and conj:collapses. So yes, this is what I am proposing. 

And also, my gut feeling is that this is exactly what RDF* does, too: you have created a new syntax, and expressed it as plain RDF using a dedicated vocabulary (detailed in 6.1) of six properties belonging to namespace https://w3c.github.io/rdf-star/unstar#. So yes, I believe that you are actually doing this already for RDF*. 

I would very much see it built using a dedicated vocabulary belonging to namespace https://w3c.github.io/rdf-star/unstar# .

>> If there is an interest in some of these topics, I would very much like to take part and contribute actively to the discussions, and I would like to know how and where and when should the discussion items be introduced.
> Well, the mailing list is a good start :)
> 
> We also use issues on the github repo [3], and finally, as stated in the end of the agenda, anyone is free to propose new topics to be added as an agenda item.

Thank you.

I do not want to derail the discussion too much, and this morning it has been quite busy, but if you tell me this is an interesting topic to pursue I will definitely put myself to this. 

Best regards

Fabio

P.S.  Andy, you're next. 

[1] https://lists.w3.org/Archives/Public/public-rdf-star/2021Aug/0000.html
[2] https://lists.w3.org/Archives/Public/public-rdf-star/2021Sep/0001.html
[3] https://github.com/w3c/rdf-star/issues/169


--

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/

Received on Friday, 17 September 2021 10:50:07 UTC