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

> On Jul 16, 2020, at 10:29 AM, Dan Brickley <danbri@danbri.org> wrote:
> 
> On Thu, 16 Jul 2020 at 15:43, Patrick J Hayes <phayes@ihmc.us <mailto:phayes@ihmc.us>> wrote:
> I just noticed that Dan already said this in his email. Sorry, Dan, but +1.
> 
> Let's talk it through.
> 
> In normal RDF, the marketplace of structures you can use to make statements operate at a painfully fine-grained level, triple by triple you can draw upon types and properties that are already in use, as well as URIs standing for the things being described.

Well, one person’s pain, etc.. But yes. 
> 
> In a "ShapedRDF" data format (and database?) there would be chunks that (could/should/must) correspond to shapes defined in SHACL/ShEx/etc., and which ...
> 
>  -in the data format, a publisher would be either asserting the whole thing, or not; 
> - in a database (e.g. accessed via SPARQL) something would ensure that it was either all there, or all gone
> - for a parser, there would be checking to not generate triples for incomplete or ill-formed shape chunks?

Yes. The fact that SHACL is seen as a syntactic constraint, rather than just another description, is touted as a big advantage of SHACL over OWL. Sounds like just what we need here. I havnt checked the details, admittedly, but the advantages of using an existing recommendation outweigh any minor places of less than perfect fit. 

OWL/RDF parsers have been in this position, doing OWL syntax checks on chunks of RDF, for over a decade. And the RDF spec does say explicitly that a semantic extension can impose syntactic conditions on RDF graphs (and keeping list descriptions well-formed was exactly what I had in mind.)

> 
> Something like RDFStar or Property Graphs could allow the shapes to be explicitly indicated in concrete syntax. But maybe that isn't needed? Perhaps the shape commitments would be declared up front at the top of the file like namespaces or json-ld @context definitions?

Yes. I imagine it being rather the relationship of CSS to HTML, where you can put all the structural specification into a file and just reference it in the RDF file header somewhere. That allows people to publicly agree on formatting (just like they do now for datatyping, by using the XML schema URI) but also allows communities to develop and use new ideas without having to reconvene a W3C WG to develop a new standard. 

Also thinking out loud. 

Pat
>  
> Thinking out loud...
> 
> Dan
> 
> 
> Pat
> 
> > On Jul 16, 2020, at 9:36 AM, Patrick J Hayes <phayes@ihmc.us <mailto:phayes@ihmc.us>> wrote:
> > 
> > Sounds like a task for SHACL, no? Ignore the nonsense about comparing it to OWL: it is a macro language for describing /syntactic/ constraints on RDF graphs. Doesn’t that give you the required atomicity?.
> > 
> > Pat
> > 
> >> On Jul 16, 2020, at 9:18 AM, David Booth <david@dbooth.org <mailto:david@dbooth.org>> wrote:
> >> 
> >> On 7/16/20 9:58 AM, Dan Brickley wrote:
> >>> I believe the big appeal of putting it all into the zone we call "literals" is that you get a kind of atomicity; that chunk of data is either there, or not there; it is asserted, or not asserted. With a triples-based (description of a ) data structure you have to be constantly on your guard that every subset of the full graph pattern is at least sensible and harmless, even when subsetting these chunks is often confusing or misleading for data consumers. I can't help wondering whether notions of graph shapes [ . . . ] could be exploited to create an RDF-based data format which had atomicity at the level of entire shapes.
> >> 
> >> +1
> >> 
> >> IMO the ability to manipulate chunks of data atomically -- arrays, n-ary tuples and hierarchical objects -- is a key requirement in developing a higher-level form of RDF.   This will include the need to conveniently construct and deconstruct such chunks in rules or query languages.
> >> 
> >> David Booth
> >> 
> > 
> > 
> 
>