Re: From syntactic to interpreted triple

> On 2021-02-08, at 21:39:12, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> Hi James,
> 
> On måndag 8 februari 2021 kl. 18:19:02 CET James Anderson wrote:
>> good evening;
>> 
>>> On 2021-02-08, at 16:42:04, Olaf Hartig <olaf.hartig@liu.se> wrote:
>>> 
>>> Hi James,
>>> 
>>> Has my solution to your exercise been satisfactory to you?
>> 
>> thank you for the extended explanation of how to proceed.
>> it does demonstrate how to engineer the requested response to that initial
>> repository state.
>> this passage, in particular, stands out:
>> 
>>> More precisely, I am assuming
>>> that the meaning of the class denoted by [the URI :claim] is as follows.
>>> Every embedded triple that is stated to be of rdf:type :claim is meant to
>>> be treated in terms of referential transparency.
>> 
>> the subsequent query, which establishes that meaning for specific relations,
>> reads less as a general mechanism for transparency, that it does as an
>> implementation for how to circumvent opacity for those specific relations.
> 
> I would not say 'circumvent opacity', but 'add transparency'. However, this 
> may be a matter of perspective.

when the context shifts from examples to implemented services and the systems constructed on top of them, perspective will matter.

> 
>> this is less than satisfactory as a mechanism to be applied to effect
>> transparency, in general.
> 
> I don't understand why you don't see the presented approach as general. I 
> mean, nothing in the approach is specific to the cars/automobiles-are-bad 
> example. In particular, none of the URIs that are specific to this example 
> (i.e., :cars, :automobiles, :are, and :bad) are mentioned in the CONSTRUCT 
> query Q_rule1. You can try with any other example: For instance, assume the 
> initial state of the dataset in the endpoint is the following.
> 
>  <<:fall :hasWeather :rainy>> rdf:type :claim .
> 
> ...and you let the endpoint know that the URIs :fall and :autumn denote the 
> same thing:
> 
> REQUEST 1:
> 
>   PREFIX owl: <http://www.w3.org/2002/07/owl#>
>   INSERT DATA { :fall owl:sameAs :autumn }
> 
> Now you can do exactly the same steps as described in my email and, in the 
> end, the endpoint will return true in response to the following query:
> 
>   PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>   ASK WHERE { <<:autumn :hasWeather :rainy>> rdf:type :claim }
> 
> So, what about the approach is not general?

:claim, its meaning, the mechanism to effect its interpretation.

> 
> Or are you asking in general for a semantics of RDF* that enforces referential 
> transparency for all embedded triples?

that would be nice.
a semantics which defers the interpretation in a _straight-forward manner_ would be better.

> If that's the case, this was not the 
> discussion that Thomas and I had when you entered. In contrast, I tried to 
> convince Thomas that, given the currently proposed semantics (which uses 
> referential opacity for embedded triples), it is still possible on top of this 
> semantics to achieve referential transparency for selected cases.
> I demonstrated a general approach for users to indicate what these selected 
> cases are and for an algorithm to act upon such indications by producing the 
> inferences as desired for these selected cases.

the described process was about what i expected.
as i noted, it "does demonstrate how to engineer the requested response”.
as you suggested, while it was specific, it could be generalized and/or replicated
this does reassure me, that i am not overlooking something.

it is unsatisfactory, as it does not reassure me that i will be able to build a general mechanism to support such assertions and investigations from applications on the order of those which target our current implementation.
i believe i understand how to represent rdf as described by the various recommendations.
this, in a manner sufficiently general and efficient to accomplish this for transactional applications which rely on kleen-star paths, hundred-operator sparql expressions, reified statements, matierialized view, and versioned data.
that depends on comprehending the potential data and access patterns and arranging efficient retrieval and combination mechanisms respective those structures. (read indices).
i am yet to image how to realize a similarly effective mechanism which “adds transparency” to embedded triples.

best regards, from berlin,

Received on Tuesday, 9 February 2021 12:50:35 UTC