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

Where do you think that there is a related mistake relating to undefined


On 11/2/20 6:10 AM, Miel Vander Sande wrote:
>>     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

Received on Monday, 2 November 2020 11:19:10 UTC