Re: RDF* semantics

Dear Olaf,

sorry for my late response, I had to defend my PhD and was therefore 
short on time. I hope that this will improve and I can give you faster 
feedback from now on.

So, now to your definition:

I see that you map cited ground triple like for example in :a :b <<:c :d 
:e>>. directly to the domain of discourse and I think it is a good 
solution (I do the same in N3).

For the triples containing cited blank nodes like :a :b <<_:x :d :e>>. 
the definition is less clear in my opinion (or I didn't understand it 
yet, which can always be the case :) ).  You write:

/"//Furthermore, define [I+A] to be the extension of I that covers all 
triples and graphs (not just ground ones) and that, ***in the condition 
for triples as given above for ground graphs**, uses [I'+A] instead of 
I'.*"/

What exactly is that condition you mean?

I am afraid that you still have the same problem with the blank nodes 
you had in the beginning: The function I' maps ground elements of your 
language into your domain of discourse and the function A maps blank 
nodes into the domain of discourse. Both functions are not defined for 
the language element <<_:x :d :e>>.   You need to add how exactly you 
extend the function [I'+A] for these cases.


In order to recommend a fix, I would like to know how you want to 
understand these blank nodes. Do they have local scope or global scope?  
More concrete:

Does :LoisLane :believes <<_:x :can :fly>>. mean:

a) "Lois Lane believes that there exists someone who can fly" (or in 
pseudo logic: believes(LoisLane, (∃x: can(x, fly)).

or

b) "There exists someone of whom Lois Lane believes that he can fly" (or 
in pseudo logic: ∃x: believes(LoisLane, can(x,fly)).

Kind regards,
Doerthe



Am 29.08.19 um 17:07 schrieb Olaf Hartig:
> 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
>
-- 
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