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

On Thu, 16 Jul 2020 at 15:43, Patrick J Hayes <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.

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?

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?

Thinking out loud...

Dan


> Pat
>
> > On Jul 16, 2020, at 9:36 AM, Patrick J Hayes <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> 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
> >>
> >
> >
>
>
>