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

Hi Aidan,

Example 2 is just a different shape of the following graph:

    laptop1
    batteryPercentage: _:fraction1

    laptop2
    batteryPercentage: _fraction2

The algorithm is going to give false negatives with one shape but not the
other, even though the meaning of the graphs is the same.

It also has the potential to give false positives. It'll generate the same
ID for both people in the following graph, even though they might not
necessarily be the same person:

    _:person1
    firstName: Mary
    lastName: Smith

    _:person2
    firstName: Mary
    lastName: Smith

I don't think there's an easy way around this sort of thing aside from
type-dependent comparison algorithms. Swift developers are used to it
actually, we have to define comparison algorithms when we define custom
types: https://developer.apple.com/documentation/swift/equatable

Regards
Anthony

On Fri, Jul 3, 2020 at 2:49 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Tue, 30 Jun 2020 at 16:47, 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.  Note to such PhD students/research:
>> pay particular attention to Sean Palmer's insightful comments also:
>> https://github.com/w3c/EasierRDF/issues/68
>>
>> IMO blank nodes have been a significant factor in pushing RDF over the
>> cognitive complexity threshold that average developers are willing to
>> tolerate.  Given how rapidly other easier-to-use graph databases have
>> become popular and have far overtaken RDF in market share, I think it is
>> URGENT that we address the problem of making RDF easier for AVERAGE
>> developers:
>> https://db-engines.com/en/ranking/graph+dbms
>
>
> If we were to say, "bnodes for dev, URIs for production", does the problem
> go away?
>
>>
>>
>>
>> David Booth
>>
>>