Re: Consolidating triple/edges

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).

> 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.

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 Friday, 15 December 2023 13:49:38 UTC