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

Re: RDF* semantics

From: Olaf Hartig <olaf.hartig@liu.se>
Date: Sat, 10 Aug 2019 07:26:56 +0000
To: "public-rdf-star@w3.org" <public-rdf-star@w3.org>, Doerthe Arndt <doerthe.arndt@ugent.be>
Message-ID: <564419a6-a78e-4285-8213-b0a928a8fe5a.maildroid@localhost>
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. 


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

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 Saturday, 10 August 2019 07:27:27 UTC

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