- From: Thomas Lörtsch <tl@rat.io>
- Date: Wed, 25 Oct 2023 11:34:48 +0200
- To: Doerthe Arndt <doerthe.arndt@tu-dresden.de>
- Cc: Niklas Lindström <lindstream@gmail.com>, RDF-star WG <public-rdf-star-wg@w3.org>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Hi Dörthe, please forgive me that I skimmed this thread, not really reading it thoroughly right now, but this here strikes me: > On 25. Oct 2023, at 00:31, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote: […] > Here is the point which surprised me that much, because in my opinion, N3 is not that different from SPARQL’s BGPs. We only have a very strict difference between graph terms and graphs. Isn’t this a pretty considerable difference?! BGP matching is usually assumed to match against statements (contained in graphs, of course), but not graph terms as I understand you/N3 to define them. So it’s quite natural that intuitions clash if suddenly graph terms are introduced into a practice that is accustomed to a quite different behavior. In another mail a few days ago I pondered if graph types shouldn’t best be represented as datatyped RDF grah _literals_. And reading Pat’s post that Niklas cited yesterday [0] I’m even more likely to find that a good idea. Queryable literals of course, not just strings - that’s why it’s important that they are datatyped as RDF. But not asserted (also quite natural for literals - they only refer to themselves) and therefore IMO the perfect way to represent and talk about an abstract type. I imagine that this would cover any "logical" applications that want to work on the abstract level, and - separation of concerns - it doesn’t get mixed up with practices that are interested in tokens. Does that make sense to you? Thomas [0] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Oct/0082.html
Received on Wednesday, 25 October 2023 09:34:59 UTC