Re: Consolidating triple/edges

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 Sunday, 17 December 2023 23:15:33 UTC