Re: drop referentially opaque semantics in embedded triples

I very much agree that there is a decided possibility that embedded triples 
are being tasked to do too much.  The largest offender here, I think, is the 
two "modes".

There is some support for opacity when embedded triples are not asserted.  But 
the main examples given for non-asserted triples appear to be modal contexts 
like believes, where the need is not for embedded triples but for entire modal 
graphs.

When embedded triples are asserted the support for opacity is very much 
diminished.  It doesn't matter which lexical form of an integer is used when 
providing qualifiers for a statement.  That is:

:berlin :population 03000000 {| :measured-by :census |}

should mean the same as

:berlin :population 003000000 {| :measured-by :census |}

In some sense the idea of using embedded triples, as opposed to a datatype for 
triples or graphs, argues for making terms in them transparent.   After all, 
if an opaque reading is what is desired just use the datatype.



I very much disagree that just being able to encode something in the standard 
RDF semantics provides compatability in any non-technical manner.  As I have 
shown, it is possible to come up with very many different meanings for 
embedded triples.  For example, just modifying the encoding of embedded triples in
https://pr-preview.s3.amazonaws.com/w3c/rdf-star/pull/162.html#mapping
to drop the blank node conditions would make blank nodes opaque. Adding the 
blank node conditions to the unstar:subject and unstar:object clauses there 
would make blank nodes irrelevant. Both these semantics are indistinguishable 
from the unmodified semantics as far as being encoded in standard RDF 
semantics goes but the second one does extreme violence to the generally 
understood principles of RDF surface syntaxes.



It is entirely possible to argue about embedded triples without worrying much 
about their precise theoretical underpinnings.  Much of philosophical logic 
was done in this manner.  We might think it quaint these days to argue about 
what conjunction is supposed to mean without invoking any technical details 
but that it not to say that such discussion is not warranted.   In particular, 
it is almost certainly the right thing to do to get the big picture right 
(e.g., transparency vs opacity) before ironing out the details (technical 
details and corner cases).  Of course the devil may be in the details, but 
details without an overall picture can easily be just formalism-induced noise.



peter



On 5/11/21 10:18 AM, Pierre-Antoine Champin wrote:
> (editor's hat on)
>
> Thomas,
>
> first of all, thanks for taking the time to write all this down. I think I 
> am getting a clearer view of your position. My take away is that maybe we 
> are trying to solve too many use-cases with a single construct (embedded 
> triples). An alternative could be to use opaque graph literals (as proposed 
> by Antoine Zimmermann) alongside transparent embedded triples. On the one 
> hand, I find this appealing. On the other hand, I am a bit concerned that 
> this may cause twice as much confusion...
>
> That being said, I also still disagree with a number of your premises. To 
> name a few:
>
> * the idea that the proposed semantics would be somewhat incompatible with 
> existing RDF and would "break common expectations". Unlike earlier versions, 
> the current semantics is entirely based on the standard RDF semantics, so 
> whatever it breaks could have been broken by RDF with or without RDF-star. 
> May be these "common expectations" about RDF need to be revised.
>
> * the idea that we can discuss this issue while deliberately ignoring its 
> theoretical underpinning. I am not dismissing social semantics and 
> philosophical considerations, I agree with you that they are also very 
> important. But they do not cover the whole picture.
>
[...]

Received on Tuesday, 11 May 2021 17:20:29 UTC