W3C home > Mailing lists > Public > public-rdf-star@w3.org > December 2020

Re: RDF* vs RDF vs named graphs

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Tue, 1 Dec 2020 09:53:52 -0500
To: thomas lörtsch <tl@rat.io>
Cc: public-rdf-star@w3.org
Message-ID: <a3a0b8fb-35e0-5be9-bec9-f9e747ab48a4@gmail.com>
I would hope that one outcome of this effort will be the beginnings of a
shared understanding of the intended meaning of << >>.  But that's a desired
outcome, and I don't think there is currently such a shared understanding. 
Once there is a shared understanding a formal semantics can be selected that
conforms to this shared understanding (to the extent that this is possible in
either the RDF semantics or a simple extension of the RDF semantics).

This lack of shared understanding extends even to just what an embedded triple
is, in my opinion.  So my view is that it is perfectly reasonable to propose
different formal accounts of embedded triples to show how different intended
meanings could be supported.  Some of these accounts might have there only
being one embedded triple for a given subject, predicate, and object.  Others
might not.  Some of these accounts might have all occurrences of << s p o >>
in a document (or globally) mapping to the same embedded triple for a given s,
p, and o.  Others might not.  Some of these accounts might need to have the
notion of an embedded triple dependent on an enclosing RDF graph.  Others
might not.


PS:  Part of the power of the semantic web, in my opinion, is that it does not
depend on complete shared understanding of the meaning of IRIs.  I am free to
use any IRI in the way that I want to.  Of course, there are costs to be paid
in diverging from a shared understanding but sometimes these costs are
outweighed by the costs of using someone else's understanding.

This makes the semantic web different from, for example, Wikidata, and even
schema.org.  Vive la difference.

On 11/30/20 2:38 PM, thomas lörtsch wrote:
> On 30. Nov 2020, at 18:57, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>> Agreed, but that makes them no different from IRIs or other blank nodes.  And,
>> in some sense, makes them no different from literals.  Although the RDF
>> semantics says what string literals denote, nowhere is this denotation made
>> identical to whatever you or I think of as a string.  There is no way for
>> formal specifications to directly connect to anything that happens in the real
>> world, assuming that there really is a real world, or in our minds, assuming
>> that we have minds.
>> And there is no reason that two occurrences of an embedded triple in an RDF
>> document must denote the same entity.  RDF* generally has this requirement,
>> and one of the test cases needs it, but it is entirely reasonable to consider
>> a version of RDF* that does not.  The only thing that you lose is that you
>> don't get that information associated with one occurrence is associated with
>> the other.
> The semantic web operates under the assumption of shared understanding about what an IRI, a literal or a blank node denote. IMO there is absolutely no reason to think that this assumption shouldn’t or can’t hold for embedded triples (or names denoting them, should they get names by mapping to reification or whatever). As soon as they become resources in the universe of discourse we may disagree about there properties - you may find them big, I may find them blue - but we have to come to some shared understanding about what they denote, which probably is informed by what their subject, predicate and object denote, which again is as well-defined in RDF as it can be under the constraints you outline above concerning the connection to the real world. 
> To become a subject of discourse however a resource requires a proper address. An embedded triple only addresses a type. An occurrence is addressed by type and location. That location may be a graph, a document or any other snippet of RDF in which the triple surfaces. That’s not much to do with meaning, minds and other metaphysical arangements.
> Thomas
Received on Tuesday, 1 December 2020 14:54:50 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 1 December 2020 14:54:51 UTC