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

Couldn't resist to put my 2 cents in.

Isn't SPARQL the language to define RDF patterns, or shapes, if you
will? The question is how those patterns/shapes are shared. One way is
the SPIN vocabulary [1], another is SHACL, which boils down to SPARQL
anyway.

Our goal was to tie such shapes to REST. In other words, create a
uniform read-write Linked Data API which allows CRUD over resource
descriptions defined by such shapes.
Allow me to plug our own work here: Linked Data Templates (LDT)
specification [2]. It defines templates as a mapping from HTTP
requests to SPARQL commands, as well as formal semantics of their
execution. These LDT templates are naturally written in RDF and
contained in composable ontologies.

To me, that enables the original Semantic Web idea by TimBL --
ontology-driven agents. We do eat our own dogfood and provide
open-source RDF publishing systems driven by LDT [3][4].

[1] https://spinrdf.org/sp.html
[2] https://atomgraph.github.io/Linked-Data-Templates/
[3] https://github.com/AtomGraph/Processor
[4] https://atomgraph.github.io/LinkedDataHub/


Martynas
atomgraph.com

On Thu, Jul 16, 2020 at 5:34 PM Dan Brickley <danbri@danbri.org> wrote:
>
> 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
>> >>
>> >
>> >
>>
>>

Received on Thursday, 16 July 2020 17:44:27 UTC