Re: From syntactic to interpreted triple

Thomas,

On fredag 5 februari 2021 kl. 17:17:39 CET thomas lörtsch wrote:
> [...]
> >>> First of all, as I already mentioned in my initial response to Thomas,
> >>> if we use a referential-opacity semantics for RDF*, then there must
> >>> be something in this data of yours that indicates that you want to
> >>> use referential transparency for this particular case. In the following,
> >>> I am assuming that the URI :claim is what gives the indication. More
> >>> precisely, I am assuming that the meaning of the class denoted by
> >>> this URI 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.
> >> 
> >> That won’t work either. You can’t just (require to) define new properties
> >> or IRIs whenever referential transparency is needed. That would lead to
> >> a balkanization of the semantic web - for what purpose? Right: to ensure
> >> that the Superman problem can be solved efficiently. This is just
> >> ridiculous.
> >> 
> >> You’ll probably have to provide a way similar to the one Pierre-Antoine
> >> outlined for referencing occurrences because it’s the embedded triple
> >> that
> >> plays different roles, not the other nodes in the assertion.
> > 
> > You are saying it. The embedded triple plays different roles. What role it
> > plays does not depend on the embedded triple itself but on the other nodes
> > in the assertion (such as the property in the predicate position of the
> > nested triple that contains the embedded triple).
> 
> No, it doesn’t.

Why not?

> The example in question is the following:
>
>    :me :travellingTo :Berlin .
>    << :me :travellingTo :Berlin >> :on : Wednesday .
> 
> It is easy to come up with scenarios where it is either important to record
> exactly which IRI was used to refer to :Berlin or where it is not important
> at all. The latter is most probably the normal case

This is a claim. Do you have something to back it up?

> (and the proposed RDF* semantics doesn’t cover it). Let’s assume the
> destination is not Berlin but a city in the east of Ukraine and we exchange
> triples with someone in Kiev or Moscow. In this secanrio the date of the
> journey will not have an influence on which semantics we choose, so the
> property shouldn’t need to change.

In have trouble understanding what exactly the modified scenario is and what 
you want to say here. Can you please describe this new scenario (the "Ukraine-
tavel") in more detail. What exactly does the data look like in this scenario? 
What is the semantics that you desire in this scenario? And, given that "in 
this secanrio the date of the journey will not have an influence on which 
semantics we choose," is there anything else instead that has such an 
influence?

Also, in your original Berlin-travel scenario above, does the actual date of 
the journey have an influence on which semantics to choose?
 
> As we all know on the semantic web the shared vocabularies have huge
> importance and took a lot of work to establish. You woud really have to
> come up up with much more substantial arguments to justify the need for
> their extension (just to cover the Superman use case, if I may repeat).

As Pierre-Antoine has mentioned in his response to this statement (which you 
have refused to respond to), existing RDF vocabularies have not been designed 
with having in mind that they may be used in nested triples. Therefore, when 
using an existing property now as the predicate in nested triples, one has to 
clarify anyways what the meaning of that property in this case is.

Then, a question is what to do with properties for which both can make sense, 
a meaning that considers the embedded triple to be referentially opaque and a 
meaning that considers the embedded triple to be referentially transparent? In 
my opinion, to avoid ambiguity in such a case, it is necessary to use 
different properties where each of them captures one of the possible meanings.

This brings m back to the questions that have have asked you in my previous 
email: Would you use the ':on' property in your Berlin-travel example also in 
nested triples in which the embedded triple is meant to be referentially 
opaque? If yes, would that ':on' property really have the same meaning in both 
cases?

I also observe that your responses to my solution to the exercise given by you 
and James so far have only side-tracked us into a discussion of whether my 
solution would require the community "to define a new property for all 
properties already defined, or at least a good part of them" (quoting from 
your last email on Jan.23). You have pushed the discussion in this direction 
without ever saying something about my solution from a technical perspective. 
Can I assume that you agree that my solution is technically correct?

Thanks,
Olaf

> 
> Thomas

Received on Monday, 8 February 2021 15:33:23 UTC