Re: RDF-star “baseline” document

On Fri, Jun 7, 2024 at 5:17 PM Peter F. Patel-Schneider
<pfpschneider@gmail.com> wrote:
>
> 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.

Agreed. As I see no simple enough way to do this (opacity being a can
of many worms), I am withdrawing this proposal at this time, and will
continue with the same testing of use cases against what we do decide
is the baseline.

For the same reasons, I agree that the simpler transparent option is a
better baseline. The concerns raised should be turned into issues and
be discussed in the WG, in light of how the baseline works with those
use cases.  (We do need to check all use cases thoroughly against
transparent reifiers. I believe they work. I also believe that usage
patterns are able to address most of the concerns; and for the
advanced, restricted ones, both OWL and literal encoding are already
available.)

Best regards,
Niklas


> 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 17:09:04 UTC