- From: Doerthe Arndt <doerthe.arndt@tu-dresden.de>
- Date: Fri, 6 Oct 2023 16:55:52 +0000
- To: Niklas Lindström <lindstream@gmail.com>
- CC: Andy Seaborne <andy@apache.org>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- Message-ID: <AD536443-AE30-402A-A6C9-F5A80E40F5A1@tu-dresden.de>
Dear Niklas, I now read your proposal and apologize for not having it done earlier (I only read the second part and thought that I have seen all). I now realize that you are so far only playing with the idea of going towards named graphs and I think that this is interesting. I would like to go this direction, but I am at the same time afraid that we cannot fix a semantics for named graphs, but if we could, that would totally be the best way to go. So hopefully I am wrong? :) I do not think that it makes sense to come up with a special semantics for blank graphs as opposed to IRI graphs since it could be that we already have blank graphs „in the wild“ which are used differently. Maybe it is easier to define the semantics of singleton named graphs, and then go that path, but I am not convinced here. Depending where we go, I could even imagine to align with N3, but in N3 we partly need the opacity because we have built-in functions acting on syntactical graph representations, but even there we could try to find a work around if we really want to go that path. So, as a summary: while I disagree with some of the details — I think for example that two occurrences of graph terms <<:s :p :o>> should have the same meaning and I do not follow Enrico’s argument that this is just like modal logic here because in modal logic we deal with logical operators while we only have predicates here, but I am looking forward to the discussion and Enrico convincing me of the opposite and I see how this could be done via named graphs — I do agree that we should decide now whether we dare to go broader (and I see that Thomas gives a clear: yes? :) ). I also think that we should take the decision to go or not to go for named graphs/N3 before discussing the details (which is difficult, because I can tell that we all enjoy detail discussions). Or do we only go that far that we say which of the proposed named graphs semantics would align with our RDF-star semantics following your blank graph rewriting while still defining a proper semantics for triple terms? Kind regards, Dörthe P.S. I do realize that this mail is rather a summary of what was said earlier than a new idea, but I assume that I am not the only one who did not read your proposal carefully, so maybe that brings others back into the discussion :) Am 06.10.2023 um 13:29 schrieb Niklas Lindström <lindstream@gmail.com<mailto:lindstream@gmail.com>>: On Thu, Oct 5, 2023 at 11:12 PM Niklas Lindström <lindstream@gmail.com<mailto:lindstream@gmail.com>> wrote: On Thu, Oct 5, 2023 at 9:17 PM Andy Seaborne <andy@apache.org<mailto:andy@apache.org>> wrote: On 05/10/2023 13:02, Niklas Lindström wrote: I have written a follow-up (ttled "Prerequisites and Requirements for Quotation in RDF") to explore some fundamental questions raised by these proposals: https://gist.github.com/niklasl/c22994e664663b6730613ecc1321c418 I look forward to analyzing this further with you. All the best, Niklas Data: _:g1 { :s1 :p1 :o1 } _:g2 { :s2 :p2 :o2 } _:g1 dc:created "2023-05-20T09:14:30Z"^^xsd:dateTime . Query: find all the graphs that were created at xsd datetime. SELECT * { ?x dc:created "2023-05-20T09:14:30Z"^^xsd:dateTime . } Result: ?x = _:blank123456789 which isn't very useful to go on and ask questions about the graphs as might be done by a UI RDF browser. That is certainly true. With nothing else that is quite useless. Just as any bnode id is in a query result (unless persistently skolemized), such as from a regular reification. And granted, you'd get the quoted triple "struct" back from your query with data like: << :s1 :p1 :o1 >> dc:created "2023-05-20T09:14:30Z"^^xsd:dateTime . But even without improved notation for blank graphs, this gives you that data today (with the arguable "bonus" of potentially multiple occurrences): SELECT * { GRAPH ?g { ?s ?p ?o } ?g dc:created "2023-05-20T09:14:30Z"^^xsd:dateTime . } There is reasonably little to no value of the blank graph id itself outside of structure (as with bnodes in general). But as this is about exploring quotation as structure, I started with the forms we have in RDF 1.1. That shows better in the "meatier" examples. The leading parts of my recent text is only about establishing behaviour. I'm in no way arguing for the usability of bnode *id:s*, other than perhaps in corner cases, such as in [1] where the repeated quoted triple could, with blank node graphs, be further condensed. Another thing your example points out is of course that, when we only get back the bnode id, there is no way to know that it is used as the name of a graph, other than by attempting to*use it as a graph in the query. (Which of course is true also for any IRI naming a graph.) This is related to the section "Blank Graphs as Appendices" [2], and a bit further below in "Can Occurrences Become Types?". It's about what is needed for this to work effectively. And as you've said before, a new term may prove to be needed. But I'm exploring if it is enough to have that information (i.e. "this is a graph") through an rdf:type for the node naming the graph (and/or a relationship from it). And that touches again upon the occurrence notion. (Which pretty much resembles the old question of what literals "are" (cf. `isLiteral(?x)` in SPARQL vs. an inferred `?x a rdf:Literal`); or our infamous RDF lists for that matter...) /Niklas [2]: https://gist.github.com/niklasl/c22994e664663b6730613ecc1321c418#blank-graphs-as-appendices /Niklas [1]: https://github.com/w3c/rdf-ucr/wiki/RDF-star-for-CIDOC-CRM-events Andy
Received on Friday, 6 October 2023 16:56:10 UTC