W3C home > Mailing lists > Public > public-rdf-star@w3.org > August 2019

Re: RDF* semantics

From: Olaf Hartig <olaf.hartig@liu.se>
Date: Thu, 29 Aug 2019 15:07:05 +0000
To: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
CC: Doerthe Arndt <doerthe.arndt@ugent.be>
Message-ID: <18659142.Rz4I4dxR2p@porty3>
Dear Dörthe,

Thanks for your valuable feedback! Responses inline ...

On fredag 23 augusti 2019 kl. 11:21:48 CEST Doerthe Arndt wrote:
> Dear Olaf,
> 
> I had a look to your definitions and they look fine to me. First,  I was
> worried, that you would leave first order logic if you quantify over
> referred triples, but with your definition you don't do that, the blank
> nodes still only refer to single resources in the domain of discourse.

Yes.
 
> I still have some remarks:
> 
>   * In general, I dislike, that you want to have two different
>     interpretations (PG mode and SA mode) for the same concept since I
>     think that this goes against the whole idea of interoperability
>     which is important in the Semantic Web (but this argument was
>     already made earlier in this list).

Distinguishing the two modes is still a fairly recent idea that is not present 
in any of my earlier documents and papers about RDF*/SPARQL*. In contrast, 
these earlier documents assume what I now call PG mode (which can be observed 
by looking at the SPARQL* query semantics, the definition of delete in SPARQL* 
update, and the mapping to standard RDF reification). The motivation for 
defining everything based on assuming PG mode was to accommodate users who want 
to have a feature for RDF that resembles the notion of edge properties in 
Property Graphs.

Introducing the SA mode now is an attempt to also accommodate users who want 
to have a feature that allows them to capture exactly what can be captured 
using standard RDF reification but in a more concise way.

For the moment, I have added the definitions of both modes into that document 
primarily to have more precise basis for discussion. We may come back to 
deciding about these modes at some later point.

>   * With your definition you always map triples using different URIs but
>     having the same meaning to the same element in the domain of
>     discourse and I am not sure whether you want that (do you?). As an
>     example let's consider superman (the classical example for
>     reification, see for example:
>     https://www.w3.org/2001/12/attributions/#superman). So, if we know
>     that the URIs :Superman and :ClarkKent refer to the same resource,
>     your definition can't make a distinction between
> 
>         :LoisLane :knows <<:Superman :can :fly>>.
> 
>     and
> 
>             :LoisLane :knows <<:ClarkKent :can :fly>>.
> 
>          If you want to use RDF* to talk about concrete triples (for
> example to add provenance etc.), a difference in the chosen URI (or the
> fact that a blank node is chosen) could be important, therefore my
> question.

I see the issue.

I have modified the definitions again to fix the problem: My solution is to go 
back to my initial definitions of IT and of the auxiliary function I', but then 
I kept the new part that I had added in Section 2.1. So, that should address 
both the issue you raise above as well as the issue you raised in your earlier 
email (referred triples that contain blank nodes had not been covered). 

I would appreciate if you could check again whether you find issues with the 
definitions.

For reference, the HTML-rendering of the current version is at:

http://htmlpreview.github.io/?https://github.com/w3c/EasierRDF/blob/master/

RDFstar/RDFstarSemantics.html

...for the previous version see: 

http://htmlpreview.github.io/?https://github.com/w3c/EasierRDF/blob/

2be8126d4c684ee8b288b97d404091860b830454/RDFstar/RDFstarSemantics.html

...and the initial version:

http://htmlpreview.github.io/?https://github.com/w3c/EasierRDF/blob/

a9d0964bb59c81bafa84b333581666b98d924bd5/RDFstar/RDFstarSemantics.html


Thanks,
Olaf


 
> Kind regards,
> Doerthe
> 
> Am 10.08.19 um 09:26 schrieb Olaf Hartig:
> > Dear Doerthe,
> > 
> > Welcome to the list!
> > 
> > You are right! Thanks a lot for checking the definitions in detail and for
> > pointing out the issue.
> > 
> > I have modified the draft to fix the issue. Note that I had to change the
> > definition of IT and the auxiliary function I' (for which I had to change
> > the third case in the definition, which makes it a recursive definition
> > now).
> > 
> > Please check again.
> > 
> > Thanks,
> > Olaf
> > 
> > 
> > 
> > -----Original Message-----
> > From: Doerthe Arndt <doerthe.arndt@ugent.be>
> > To: public-rdf-star@w3.org
> > Sent: Fri, 09 Aug 2019 14:49
> > Subject: Re: RDF* semantics
> > 
> > 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/maste

> >> r/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 Thursday, 29 August 2019 15:07:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:56 UTC