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

>
> 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.
>

I can only say +1 to this one. Let's not make the same mistake of leaving
the semantics undefined. For the applications that are satisfied with RDF
and SHACL, this might a less apparent problem. But there are others... And
even if you decide to embed them in URIs, you'd still need to know what
they mean. Honestly, this approach feels like an engineering hack to me,
even without taking the contested theoretical/academic perspective on the
matter.

From working on Triple Pattern Fragments (which is related in a sense,
because it defines a standard approach for encoding triples as URIs - tbh,
I think we even made the reification argument in the first paper), I can
also note that a maximum URI length is an issue in practice, which is a
potential issue for anything Linked Data.

Cheers,

Miel