Re: owl:sameAs/referential opacity Re: Can RDFstar be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)

On 30/10/2020 00:54, Holger Knublauch wrote:

>
> On 10/30/2020 8:25 AM, thomas lörtsch wrote:
>> But introducing a new node type to me feels like a much graver
>> intervention into the RDF semantics than defining a mapping from
>> statements to IRIs. 
... unless these IRIs encoding statements are so special that they must
be handled differently from other IRIs. In practice, this amount to
introduce a new node type, while being in denial about doing it...
>
> Yes exactly. We are all thinking out loud here and the outcome is
> likely going to be some glued-on patch that isn't going to be perfect
> from a theoretical POV. But the fact that RDF is already widely used
> and implemented is an opportunity, not a problem.
Amen to that!
> Therefore, I think the minor issue with the potential leakage when
> triple IRIs with blank nodes get written to Turtle is perfectly
> acceptable and pragmatic.

I don't think it is pragmatic to allow RDF* systems to produce Turtle that

* breaks the expectations of legacy RDF systems, by producing
statement-encoding IRIs that are not globally scoped, because they
actually embed some internal identifier of the source system;

* is not even compatible with other RDF* systems, if we do not specify a
single way to generate these statement-encoding IRIs (as discussed
previously in this thread).

> A simple solution would be that the applications throw an error or a
> warning if they encounter such triples, so going from TTL* to TTL will
> simply not happen in practice.

Yes, that would be much better. But, as I wrote above, it amounts to
acknowledge that these statement-encoding IRIs are, in fact, different
from other IRIs. So they are a new type of nodes.

Just to be clear: /implementing/ that new type of nodes by piggybacking
the internal IRI type is perfectly fine, as long as the implementation
behaves in an interoperable way (i.e. it produces the correct Turtle*,
and refrains from producing bogus Turtle). But specifying this
interoperable behaviour is better achieved, I think, through an extended
abstract syntax and semantics.

  best

>
>
> Holger
>
>
>