- From: Doerthe Arndt <doerthe.arndt@ugent.be>
- Date: Fri, 9 Aug 2019 14:47:54 +0200
- To: public-rdf-star@w3.org
- Message-ID: <1f0873f0-4cd5-3718-e351-4d9409551c21@ugent.be>
Dear Olaf, all, I just recently joined the list and therefore did not introduce myself yet. I am Doerthe Arndt from imec ugent and I am about to finish my PhD about Notation3 Logic. I am also involved in the N3 community group (https://www.w3.org/community/n3-dev/). I joined this mailing list because I am interested in the connection between the semantics of N3's cited formulas (if you are interested on my view on it, you find a model theory in my recent paper: https://authors.elsevier.com/a/1ZWg55bAYUaMkH) and the semantics of RDF*. I hope that these can be aligned, but even if not, I am always interesting in contributing to the definition of a model theory. Now, back to the topic (sorry for all the introducing blabla ;) ): I had a look into your definition and as far as I see (but maybe I am just missing something?), you currently don't cover referred triples which contain a blank node. As far as I can see, the expression :a :b << _:x :p :o>>. has no meaning. All your definitions are on ground formulas (= formulas without blank nodes, or do you define them differently?) and I suppose, you expect RDF's grounding mechanism to help you finding the meaning for the above triple. Unfortunately, the functions A which are mentioned in section 2.1. in your definition maps blank nodes directly to resources in the domain of discourse which leaves you without a mapping from << _:x :p :o>> to a resource. Or do you expect your mapping IT to also cover these cases? Kind regards, Doerthe Am 09.08.19 um 11:23 schrieb Olaf Hartig: > Dear Pat, all, > > As promised in my initial email in this thread (see below), I have > created a draft document that specifies how the definitions in "RDF 1.1 > Semantics" have to be extended to provide a model-theoretic semantics > for RDF* graphs. > > Please find the draft in the following github repo of the W3C RDF-DEV CG > > https://github.com/w3c/EasierRDF > > You can also read the latest version of the draft rendered directly from > github (which means you don't have to download the repo first). To his > end, use the following link. > > http://htmlpreview.github.io/?https://github.com/w3c/EasierRDF/blob/master/RDFstar/RDFstarSemantics.html > > I am looking forward to your feedback on this draft. > > Thanks, > Olaf > > > On Mon, 2019-08-05 at 16:09 +0200, Olaf Hartig wrote: >> Dear Pat, all, >> >> Great to have you on board. Your help will be much appreciated! >> >> In the following, I am responding to the points raised by Pat: >> >> On Mon, 2019-07-08 at 09:04 -0700, Patrick J Hayes wrote: >>> [...] >>> I believe that RDF* would benefit from being given a clear direct >>> semantics of its own, rather than via a reduction mapping to RDF. >> I agree. In fact, I have already started a draft that specifies how the >> definitions in Sec.5 of the "RDF 1.1 Semantics" have to be extended to >> provide a model-theoretic semantics for RDF* graphs. I will share once I >> have cleaned it up. >> >>> [...] >>> RDF* seems to presume that making an assertion about a triple also >>> thereby asserts the triple. This is not how reification was designed >>> to work, and it is in violation of the description of the semantics >>> of reification in the RDF specs. Thus, RDF* is currently not a correct >>> modeling of RDF reification. This issue needs to be addressed and >>> resolved. >> Your observation is correct: The RDF*-to-RDF mapping (and the >> corresponding SPARQL*-to-SPARQL mapping) as defined in my earlier papers >> are based on the assumption that a nested RDF* triple t also asserts the >> triple that is the subject or the object of t. Hence, my definitions of >> these mappings use the RDF reification vocabulary to capture this >> assumption. I do not think that using the RDF reification vocabulary in >> this way is a violation of the RDF specs. Note that I have *not* been >> using RDF* to model RDF reification (rather the other way around), and >> indeed I agree that making the aforementioned assumption is not a >> correct modeling of RDF reification. >> >> At this point it may be helpful to emphasize that my initial perspective >> on RDF*/SPARQL* (as reflected in the definitions in my papers) has been >> influenced by discussions with triplestore vendors who were interested >> in a practical, reification-like feature to capture and to query >> statement-level annotations. The general intention was that this feature >> would be used in a way like people use the notion of edge properties in >> Property Graph databases (if you are not familiar with Property Graphs: >> an "edge property" is a key-value pair associated with an edge in such a >> graph). Then, the aforementioned assumption followed from this intention >> because, in a Property Graph, to assign edge properties to an edge, the >> edge must exist in the graph. >> >> Having said that, I understand that there also are use cases for which >> the aforementioned assumption is unsuitable; that is, use cases in which >> asserting a nested RDF* triple t should *not* entail the assertion of >> the triples that occur in t. My current idea for the RDF*/SPARQL* >> approach to also cover such use cases is to introduce two different >> modes of how RDF*/SPARQL* may be used: One of these modes explicitly >> makes the aforementioned assumption; this is the mode that is captured >> by the existing documents and it might be called the "Property Graph >> mode" (PG mode, for short). The other mode does not make the assumption; >> it might be called the "separate-assertions mode" (SA mode). It is not >> difficult to adapt the existing definitions to capture this SA mode as >> an alternative to the PG mode. Apparently, the model-theoretic semantics >> for RDF* graphs will also differ depending on whether PG mode or SA mode >> is used, and so will the semantics of SPARQL* update operations and of >> SPARQL* queries. >> >> As an example regarding the latter, consider an RDF* graph that contains >> only the following nested triple (prefix declarations omitted). >> >> ( (:bob, foaf:age, 23), dct:creator, :crawler1 ) >> >> Furthermore, assume the following SPARQL* query. >> >> SELECT * WHERE { :bob foaf:age ?a } >> >> In PG mode, the result of this query over the given RDF* graph consists >> of a single solution mapping m with m(?a)=23. In contrast, in SA mode, >> the query result is empty. >> >> I am looking forward to comments on the idea to introduce these two >> modes of usage. >> >>> I propose an idea for consideration by this community, to allow for >>> meta-descriptions to apply to entire RDF graphs rather than restricted >>> to single triples. The costs of this seem relatively small and the >>> benefits quite great. >> While I do not know what exactly you aim to propose, what you write >> sounds more related to a discussion of named graphs. The RDF*/SPARQL* >> approach is explicitly focused on statement-level metadata rather than >> graph-level metadata, which IMHO are orthogonal concerns. >> >> Best, >> Olaf >> >> > -- Dörthe Arndt Researcher Semantic Web imec - Ghent University - IDLab | Faculty of Engineering and Architecture | Department of Electronics and Information Systems Technologiepark-Zwijnaarde 122, 9052 Ghent, Belgium t: +32 9 331 49 59 | e: doerthe.arndt@ugent.be
Received on Friday, 9 August 2019 12:49:04 UTC