Re: RDF* semantics

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.

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

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

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