Re: RDF* semantics

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
> 
>

Received on Friday, 9 August 2019 09:23:34 UTC