RDF* semantics

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 Monday, 5 August 2019 14:09:54 UTC