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

Am .07.2020, 13:02 Uhr, schrieb David Booth <david@dbooth.org>:

> On 6/30/20 6:45 PM, Aidan Hogan wrote:
>> develop methods to skolemise blank nodes, converting them into IRIs and  
>> assigning them consistent canonical labels. So if you don't want the  
>> headache of dealing with blank nodes (as common in legacy data), there  
>> is always the option of eliminating the blank nodes by skolemising as  
>> part of a pre-processing step (though it would of course require an  
>> additional dependency in the project to include the skolemisation code).
>
> Yes, excellent work!  I think skolemizing may be useful as an underlying
> mechanism, largely hidden from users.

But isn't that a compromise, then? From the perspective of data modelling  
and creation in RDF, blank nodes are a very natural and convenient tool,  
if not to say essential, at times -- e.g., when creating nonterminal nodes  
with SPARQL update, where the creation of novel URIs based on BIND  
operations that derive new URIs from the URIs of other variables in the  
context is complicated, error-prone, hard to justify to beginners and  
often impossible to do in a way that leads to a consistent URI schema  
(simply because we do not necessarily have access to the complete context  
during an update operation).

But just requiring skolemization as an obligatory part of a data  
publication process in accordance with whatever EasierRDF specification  
will arise out of this discussion (say, in a post-processing step to data  
creation) would eliminate them from the consumer perspective. (I guess  
your "users" are people/tools that consume third party data, not the ones  
actually working with that data -- but they are users of the technology,  
too.)

So, instead of discussing cons and pros of blank nodes (there are either),  
can we maybe try to focus on strategies to enforce and facilitate  
skolemization, and preserve blank nodes as a modelling option for the  
creation and transformation of data? Then, the only modification to the  
RDF 1.1 spec is that *publicly exposed* RDF data should be skolemized. I  
guess that would be a best practice everyone should be able to live with.

Otherwise, this is effectively already a part of the RDF 1.1 spec  
(https://www.w3.org/TR/rdf11-concepts/#section-skolemization), except that  
we may want to change the wording of this paragraph for the "EasierRDF"  
specification from MAY, MUST and SHOULD into MUST (not for RDF, just for  
the EasierRDF fragment).

Just my 2ct,
Christian

Received on Wednesday, 1 July 2020 12:55:32 UTC