- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 2 Nov 2020 06:18:56 -0500
- To: public-rdf-star@w3.org
Where do you think that there is a related mistake relating to undefined semantics? peter 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