Re: RDF-star “baseline” document

At this point, I think that we should not be devoting resources to new ways of 
doing things.  We have had a few ways of providing semantics for triple terms 
already and I think we should stick to them.

peter


On 6/7/24 09:37, Niklas Lindström wrote:
> On Thu, Jun 6, 2024 at 7:01 PM Peter F. Patel-Schneider
> <pfpschneider@gmail.com> wrote:
>>
>> As far as I can tell the base semantics here is fully opaque triples.
> 
> Yes, the attempt is to "ground" on those, but get back into the
> interpretation. There are obvious problems.
> 
>> Is the well-formed semantics a separate semantics?
> 
> No, I'm sorry; I just updated it to exactly follow Enrico's, i.e. RDF,
> first Simple Semantics, then RDF Semantics (which as per Enrico's
> design now includes the well-formedness, IIUC). (Link to diff at [1].)
> 
>> The statement entailment axiom appears to be ill-formed.  The axiom has access
>> only to the semantics.  So it can only see elements of the extension of
>> rdf:tokenOf as they exist in the semantics.  As s, p, and o work on triple
>> terms, not literal values, they cannot be used in the axioms.  To make this
>> work you have to add something to the definitional part of the semantics.
> 
> I see what you mean. (This part is what I'm worried about.) It might
> make use of the RE from Enricos' proposal ("An injective function RE
> from IR x IP x IR into IR, called the denotation of transparent triple
> terms."). But I've tried to avoid even more pattern matching of
> predicates to "enable transparency". I suppose I cannot use tuples (`<
> ... >`) as part of the interpretation? Otherwise, something like:
> `[I+A](r) = < IL(SRE(r)), <[I+A](r.s), IS(r.p), [I+A](r.o)> >` if `r`
> is a `tripleTerm`; to make it denote the *pair* of syntactic and
> interpreted constituent denotations...
> 
> (For those who can stand my analogies: I guess it's like I'm
> attempting pointer arithmetics on Java references. :P)
> 
>> In the end, this proposal is very much like the CG result,  To see this look
>> at the unstar section of the both documents, where in one there is rdf:tokenOf
>> link to a triple of syntactic tokens and in the other there are several
>> lexical links.  The differences amount to this proposal using RDF reification
>> vocabulary and the CG result having transparent blank nodes.
> 
> Yes, it's not unlike the CG design. The attempt is to "anchor" triple
> tokens in an opaque triple literal, but also entail a RDF reification.
> The motivation is to be simpler and "closer to RDF intuitions", while
> catering for a "fixed, atomic triple" for exact triple provenance
> *and* build qualifications upon the meaning of that.
> 
> This could get noisy on the list? I would love to work through it on
> the SemTF call. I am also not sold on it; I of course also seek a way
> to "cater for everything (sensible)" while adding as little as
> possible.
> 
> What is "sensible" is paramount. Even if this particular attempt
> fails, I hope that the section "Compatibility With Existing Use Cases"
> is helpful in general. (I added one on Wikidata and updated some of
> the others (diff at [1]).)
> 
> Best regards,
> Niklas
> 
> [1]: <https://github.com/w3c/rdf-star-wg/wiki/Proposal:-Triple-Tokens-Entailing-Reified-Statements/_compare/ac27c20a0d987432c14fd3b72610502c992905a4...26dd1bba37960b0e008966048024ec8139b26208>
> 
> 
>> peter
>>
>>
>> On 6/6/24 10:12, Niklas Lindström wrote:
>>> I do share these concerns, as well many of the concerns that Thomas
>>> expressed (the unasserted aside; I am not as worried about that).
>>>
>>> I know that once one has grasped the distinction, the choice of opaque
>>> or transparent is "obvious"; but history has shown that this is not
>>> easy to grasp. It's not about the "quotes", it's about the distinction
>>> between tokens and interpretations. And not even the formal syntax (g)
>>> vs. interpretation/model (I), but about exposing it in the domain of
>>> discourse; for developers and users with a wide range of backgrounds,
>>> training and assumptions. In a way, I think this proposal is good in
>>> part *because* it can show how difficult that can become.
>>>
>>> As Andy also replied, we did talk about there being a connection
>>> between the opaque and transparent triples. But I'm not sure this
>>> baseline proposal explains how to make the connection. And I agree,
>>> there should be one (perhaps even must be, to prevent users from
>>> accidentally painting their data into a corner).
>>>
>>> Taking as much as I could into consideration, I've written an
>>> alternative proposal, attempting to simplify this by removing
>>> transparent triples (gasp!) and then betting on it being feasible to
>>> entail transparent statements from their tokens.
>>>
>>> I just put it at [1], *far* too late for the call today. But based on
>>> where the discussion goes, it might be up for debate on tomorrow's
>>> SemTF telecon. I know e.g. Enrico won't like it -- I'm not even sure
>>> *I* do -- but if the opaque functional "triple token" point is deemed
>>> necessary, it may be better to root everything in that; *if* it can
>>> also be "peeked into".
>>>
>>> (Its Achilles' heel is probably the notion of a "B-function" (from
>>> Dörthe's options) to go from a literal-like triple to its
>>> interpretation. It also adds a "hop" to get to the "real reifier",
>>> using a qualifiedBy relation. I do think there is a common prior
>>> pattern to that though, so, for better or worse, it may be more
>>> recognizable... It echoes what I've seen in Wikidata, as well as
>>> "option 2: sugar+" from the "seeking consensus" table [2]. There is
>>> also no apparent need for a naming syntax with this alternative (it is
>>> neutral to that).)
>>>
>>> All the best,
>>> Niklas
>>>
>>> [1]: <https://github.com/w3c/rdf-star-wg/wiki/Proposal:-Triple-Tokens-Entailing-Reified-Statements>
>>> [2]: <https://htmlpreview.github.io/?https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.html>
>>>
>>>
>>> On Thu, Jun 6, 2024 at 2:13 PM Peter F. Patel-Schneider
>>> <pfpschneider@gmail.com> wrote:
>>>>
>>>> I have three concerns with this as a baseline.
>>>>
>>>> First, it is complex, with two different kinds of triple terms.  I think that
>>>> the baseline should be a simple extension that meets the requirements of most
>>>> of the use cases.
>>>>
>>>> Second, opaque triple terms are completely opaque, with blank nodes treated
>>>> just like IRIs.  Although there is a use case that requires opaque blank nodes
>>>> I don't see how opaque blank nodes are suitable for use cases like annotations
>>>> or provenance.
>>>>
>>>> Third, there does not appear to be any connection between transparent and
>>>> opaque triple terms.
>>>>
>>>> peter
>>>>
>>>>
>>>> On 6/3/24 17:29, Franconi Enrico wrote:
>>>>> Hi all,
>>>>> as promised, I’ve prepared a document defining the current status of RDF-star,
>>>>> according to what I understood from our latest chats.
>>>>> It is mainly a merge of the two previous documents about the two profiles.
>>>>>
>>>>> The idea is that RDF with simple interpretations has two triple terms
>>>>> (transparent and opaque) and unrestricted syntax for them. There is no other
>>>>> adde special vocabulary.
>>>>> On the other hand, RDF with RDF interpretations introduces the special
>>>>> vocabulary for reification, restricts the syntax of triple terms as usual (the
>>>>> “well formed” fragment), and specifies the functionality of the annotation in
>>>>> the reification of opaque triple terms.
>>>>>
>>>>> You may notice that I changed rdf:annotationOf with rdf:hasAnnotation, in
>>>>> order to allow for direct literal annotation to opaque triple terms - not
>>>>> orthodox but useful I guess.
>>>>>
>>>>> Here it is:
>>>>> https://github.com/w3c/rdf-star-wg/wiki/RDF-star-"baseline"
>>>>> <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-"baseline">
>>>>>
>>>>>
>>>>> Cheers
>>>>> —e.
>>>>>
>>>>>
>>>>

Received on Friday, 7 June 2024 15:17:57 UTC