Re: Consolidating triple/edges

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.


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.

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 12:39:01 UTC