- From: John Walker <john.walker@semaku.com>
- Date: Sun, 17 Mar 2024 08:45:00 +0000
- To: "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- Message-ID: <DB6PR02MB319271AC03930ACBABC944289A2E2@DB6PR02MB3192.eurprd02.prod.outlook.com>
Hi Enrico, James, Then in this proposal would such a named triple be a special case of a named graph containing one and only one statement. Is that a correct interpretation? If so, being very simple here, could one entertain introducing a TRIPLE keyword somewhat analogous to GRAPH into the grammar for SPARQL and constrain that to only allow a single triple pattern. WHERE { GRAPH ?g { ?s ?p ?o . TRIPLE ?t { ?s ?p ?o } ?t ?t_p ?t_o . } } I could imagine for SPARQL Graph Store HTTP Protocol to introduce a triple query string parameter analogous to graph that would only allow payloads that encode a single triple. Similarly for formats like TriG and JSON-LD that support encoding quads (datasets) a TRIPLE keyword might be added. Perhaps only formats like N-Quads might have some ambiguity whether the label in the 4th position identifies a graph or a triple, but I’m not even sure if the distinction matters. As in a graph that contains a single triple may be treated as a named triple. So, it’s more a syntactic distinction than a semantic one as you can already apply such a pattern with named graphs. Probably some naysayers will point out this does not allow for naming statements without asserting them, but you can’t make an omelette without breaking some eggs. For such cases just put your asserted statements in the default graph and your unasserted statements in named graphs/triples. Then when querying form your dataset using FROM and FROM NAMED as befits your use case. Regards, John Walker Principal Consultant & co-founder Semaku B.V. | Torenallee 20 (SFJ 3D) | 5617 BC Eindhoven | T +31 6 42590072 | https://semaku.com/ KvK: 58031405 | BTW: NL852842156B01 | IBAN: NL94 INGB 0008 3219 95
Received on Sunday, 17 March 2024 08:45:08 UTC