Re: Consolidating triple/edges

Hi Thomas,

Thanks for confirming that you are aware that triple terms need to be
referentially opaque in order to be suitable as a building block for
the things that you are outlining with these rdfx:asserts, rdfx:quotes,
and rdfx:reports properties.

Best,
Olaf


On Mon, 2023-12-18 at 00:15 +0100, Thomas Lörtsch wrote:
> Hi Olaf,
>
> > On 15. Dec 2023, at 14:49, Olaf Hartig <olaf.hartig@liu.se> wrote:
> >
> > Hi Thomas,
> >
> > On Fri, 2023-12-15 at 13:38 +0100, Thomas Lörtsch wrote:
> > > Hi Olaf,
> > >
> > > thanks for the comment!
> > >
> > > > On 14. Dec 2023, at 23:12, Olaf Hartig <olaf.hartig@liu.se>
> > > > wrote:
> > > >
> > > > Thomas,
> > > >
> > > > If "the triple ':liz :spouse :dick .' doesn’t have to be added
> > > > to
> > > > be asserted [but] Instead the property rdfx:assertionOf asserts
> > > > it," then the evaluation of SPARQL basic graph patterns (under
> > > > simple entailment) is not anymore simply a matter of pattern
> > > > matching.
> > > >
> > > > For instance, to determine the solution mappings for a triple
> > > > pattern such as
> > > >
> > > >   (?x, :spouse, :dick)
> > > >
> > > > it would not anymore be sufficient to look (in the queried
> > > > graph)
> > > > for all the triples that match this triple pattern but,
> > > > additionally, the objects of rdfx:assertionOf triples would
> > > > need to
> > > > be considered too.
> > > >
> > > > Hence, this would require a fundamental change to the
> > > > definition
> > > > (and the implementations) of SPARQL, which I don't think most
> > > > vendors would be happy with.
> > >
> > > I talked to a well-known RDF implementor and consultancy recently
> > > and
> > > they told me that they use owl:imports to work around the
> > > tediousness
> > > of having to explicitly name graphs in SPARQL queries, i.e. they
> > > owl:import other named graphs into the named graph from which
> > > they
> > > start queries. That sounded like a pretty dynamic arrangement to
> > > me.
> > >
> > > Nothing would prevent stores to materialize statements that are
> > > entailed from the aforementioned rdfx:assertionOf relation. They
> > > would only need to make sure that such entailed statements are
> > > removed when the originating "asserting" relation is deleted (and
> > > no
> > > other such relation refers to the same statement).
> > >
> > > Not that your concern is not justified - it certainly is.
> > > However, in
> > > practice the difference is rather if users have to add the
> > > asserted
> > > statement by themselves or if the machinery can/should be trusted
> > > to
> > > do that for them. In fact what you say could be ironically turned
> > > into "machines can’t be trusted to add that entailed triple, it’s
> > > better if users have to add it manually". I guess understanding
> > > (and
> > > implementing) the process as early materialization rather then
> > > per-
> > > query-entailment makes the difference.
> >
> > If your concern is about users having to explicitly write the
> > asserted
> > triples in addition to writing them as triple terms when
> > introducing
> > their occurrence names, I don't think you need to worry too much
> > about
> > it. Users who manually write RDF data are likely using Turtle
> > rather
> > than the N-Triples format and, thus, they can use the shorthand
> > notation that you proposed earlier and that Andy picked up in his
> > initial email of this thread. For SPARQL users, the same kind of
> > shorthand notation can be added to the (user-facing) syntax of the
> > language. For users who create RDF data through programming
> > libraries,
> > the APIs of such libraries can be extended to provide similar
> > shortcuts
> > (similar to how many of them do it for, e.g., RDF collections).
>
> I have trouble to think in different serializations all at once ;-)
>
> True, the shorthand syntax (TopBraid's proposal, not mine - I just
> added the identifier) doesn’t have that problem, but it also can’t
> talk about unasserted triples and can’t annotate triples in object
> position. So I prefer to check the more verbose serialization first
> (or at least just as much).
>
> TBH I find my own proposal a bit daring in that it puts a lot of
> cognitive load on users ("if you write ':X rdfx:asserts << s p o>>',
> then imagine that you also write 's p o'"), but I still like the way
> that it automates what is anyway implied. One could also say (to
> lessen the cognitive load): "if you use the ':X rdfx:asserts << s p
> o>' construct, then 's p o' _is_ added to the database. Of course you
> may still write it out for clarity."
>
> > > A slight modification of the proposal IMO makes it even more
> > > interesting. Imagine that we have different properties:
> > > 'rdfx:assertionOf', 'rdfx:quoteOf', 'rdfx:standardReificationOf'
> > > and
> > > maybe even more.
> > > - 'rdfx:assertionOf' asserts the statement to which is creates a
> > > reference (and as discussed above either the user or the
> > > machinery
> > > are required to materialize it).
> > > - 'rdfx:quoteOf' doesn’t assert it and clarifies that the
> > > reference
> > > it creates is referentially opaque
> > > - 'rdfx:standardReificationOf' (which of course is a lousy name)
> > > like
> > > 'rdfx:quoteOf' doesn’t assert the statement but refers to its
> > > referentially transparent representation, as does RDF stamdard
> > > reification.
> >
> > Perhaps that's indeed an idea to think about. Notice, however, to
> > be
> > able to do that, the triple term (as would be used in the object
> > position of a triple with such a property as predicate) needs to be
> > referentially opaque by default, and for some of these properties
> > ('rdfx:assertionOf' and 'rdfx:standardReificationOf'), the token
> > that
> > is introduced with them can then be treated as referentially
> > transparent. It cannot be the other way around if we want to keep
> > the
> > monotonicity of RDF semantics, as we extensively discussed during
> > the
> > CG times.
>
> I’m well aware, and I started to like that while I was working on the
> cofigurable semantics part of the nested named graph proposal. Notice
> my wording above: the semantics of the references created vary, not
> the semantics of the term from which they are created. This makes
> them pretty useful and less dangerous with very little effort
> (caveat: this is still a new-ish idea, so it may contain bugs).
>
> One example:
>
>     :Alice :buys :Car {| id:1 | :src :Bob }
>
>
> is equal to
>
>     id:1 rdfx:asserts << :Alice :buys :Car >> ;
>          :src :Bob .
>     :Alice :buys :Car .        # entailed from rdfx:asserts
>
> Obviously, the shorthand syntax is more concise in this case - which
> can also be assumed to be the standard and most customary case. But
> the increase in verbosity and complexity is modest, whereas the
> increase in expressivity is enormous.
>
> Unasserted assertion, referentially opaque (for e.g. versioning):
>
>     id:1 rdfx:quotes << :Alice :buys :Car >> ;
>          :src :Bob .
>
> Unasserted assertion, referentially transparent (for e.g. reported
> speach):
>
>     id:1 rdfx:reports << :Alice :buys :Car >> ;
>          :src :Bob .
>
> Assertion, referentially opaque (for e.g. documenting initial state):
>
>     id:1 rdfx:reports << :Alice :buys :Car>> ;
>          :src :Bob .
>     :Alice :buys :Automobile .
>
> Plus of course: triple terms pave the way to graph terms. The
> shorthand syntax doesn’t seem expandable to groups of triples - at
> least I can’t see a sensible way to do so (that of course is not
> meant as a critique).
>
>
> Best,
> Thomas
>
> > Best,
> > Olaf
> >
> >
> > > This would solve a few problems. For example it would now be
> > > possible
> > > to disambiguate annotations on unasserted statements from
> > > annotations
> > > on the same, but asserted statement. The current proposal can’t
> > > do
> > > that.
> > > It would also prevent the leaking of referential opacity into
> > > stamdard RDF. In the current proposal it is possible to claim
> > > that an
> > > annotated statement is meant to be referentially opaque, despite
> > > all
> > > RDF statements being referentially transparent, because it was
> > > created together with or even "from" an opaque annotation. That
> > > may
> > > be a rather sublime problem, but it is not easy to solve.
> > >
> > > Of course more properties are possible. The nested graph proposal
> > > introduces a 'record': an asserted, but referentially opaque
> > > statement. So far it is just a fudge, waiting for some
> > > semanticists
> > > to comment on it. The whole direction is of course N3-like
> > > configurable semantics.
> > >
> > > Thomas
> > >
> > >
> > > > Olaf
> > > >
> > > > Dec 14, 2023 20:46:46 Thomas Lörtsch <tl@rat.io>:
> > > >
> > > > > > On 14. Dec 2023, at 19:21, Andy Seaborne <andy@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 14/12/2023 16:46, Thomas Lörtsch wrote:
> > > > > > > ## Unasserted vs Asserted
> > > > > >
> > > > > > Just on this part:
> > > > > >
> > > > > > > Why not define a property that not only references a
> > > > > > > token,
> > > > > > > but also creates the triple, e.g.:
> > > > > > >   :liz :spouse :dick [id:1]{| :start 1964; :end 1974 |} .
> > > > > > > mapping to
> > > > > > >    id:1 rdfx:assertionOf << :liz :spouse :dick >>
> > > > > > >        :start 1964; :end 1974 .
> > > > > > > instead of
> > > > > > >    id:1 rdfx:occurrenceOf << :liz :spouse :dick >>
> > > > > > >        :start 1964; :end 1974 .
> > > > > > >    :liz :spouse :dick .
> > > > > >
> > > > > > Yes - that is the meaning of {| |}
> > > > > >
> > > > > > Starting at:
> > > > > > > > which would map to
> > > > > > > >   id:1 rdfx:occurrenceOf << :liz :spouse :dick >> ;
> > > > > > > >        :start 1964; :end 1974 .
> > > > > > > >
> > > > > > > >   id:2 rdfx:occurrenceOf << :liz :spouse :dick >> ;
> > > > > > > >        :start 1975; :end 1976 .
> > > > > >
> > > > > > I added the
> > > > > >
> > > > > > > and asserting:
> > > > > > >  :liz :spouse :dick .
> > > > >
> > > > > A misunderstanding: I’m proposing that the triple ':liz
> > > > > :spouse
> > > > > :dick .' doesn’t have to be added to be asserted. Instead the
> > > > > property rdfx:assertionOf asserts it, like owl:imports
> > > > > asserts a
> > > > > referenced ontology in the importing graph.
> > > > >
> > > > > Because the property asserts the statement and adds an
> > > > > identifier
> > > > > to that occurrence it is possible to know exactly to which
> > > > > occurrence an annotation belongs (also if it is actually
> > > > > intended
> > > > > to be asserted or not, because if not, use another property
> > > > > like
> > > > > e.g. rdfx:quotes).
> > > > >
> > > > >
> > > > > > because it wasn't in the description that started this:
> > > > > > https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0024.html

> > > > > >
> > > > > > As the original CG annotation syntax did assert, I assumed
> > > > > > it
> > > > > > was implied to happen as well.
> > > > > >
> > > > > >   Andy
> > > > > >

Received on Monday, 18 December 2023 15:02:41 UTC