W3C home > Mailing lists > Public > semantic-web@w3.org > June 2020

Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

From: Patrick J Hayes <phayes@ihmc.us>
Date: Tue, 30 Jun 2020 14:12:25 -0500
CC: <semantic-web@w3.org>
Message-ID: <F8D9E49B-0947-4AEC-BB01-08B97579D027@ihmc.us>
To: David Booth <david@dbooth.org>


> On Jun 30, 2020, at 9:40 AM, David Booth <david@dbooth.org> wrote:
> 
> On 6/29/20 7:33 PM, Aidan Hogan wrote:
>> For what it is worth, we started working on the topic of blank nodes some time ago similarity convinced of the fact that the RDF semantics of blank nodes was unintuitive, and that a better semantics could be found. A couple of papers and several years later, I was/am more or less convinced that the semantics of blank nodes is as it should be in RDF.
> 
> While I appreciate the very thorough technical analysis that Aiden has done, and I don't exactly disagree with his technical conclusion, after years of consideration I've come to look at the problem differently and have reached a different conclusion: we should not be dealing with blank nodes AT ALL.  Blank nodes should be ELIMINATED from the user experience.  We need to move to a higher-level representation that does not have blank node labels, so that users never need to think about them or be baffled at the semantic subtleties that have dogged these discussions for so long.  Blank nodes should exist ONLY in the underlying machinery that users NEVER need to touch or see.
> 
> In practical terms, this means adopting a new, higher level RDF-based syntax that allows RDF tooling to be reused as much as possible.
> 
> A minimum contender would be Turtle/TriG without blank node labels, but if we are contemplating a new syntax then I personally think it would be worth making a few more changes at the same time, to make it even higher level and easier to use.  A number of ideas have been collected here, though somewhat haphazardly:
> https://github.com/w3c/EasierRDF/issues
> 
> But note that a new RDF-based syntax is only one part of the entire tool chain.  A SPARQL successor would also be needed, to support the new features and restrictions, and libraries would have to support them also.
> 
> I REALLY wish that some PhD students would take on this challenge: to design a higher-level successor to RDF, with a top-line goal of making it easy enough for AVERAGE developers (middle 33% of skill), who are new to it, to be consistently success. 

Might that be (a subset of?) OWL2 using the Manchester syntax?

Pat
Received on Tuesday, 30 June 2020 19:12:46 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:46:04 UTC