W3C home > Mailing lists > Public > public-rdf-star@w3.org > August 2020

Re: RDF* implementations and PG/SA modes (updated list)

From: Andy Seaborne <andy@apache.org>
Date: Tue, 18 Aug 2020 19:00:41 +0100
To: public-rdf-star@w3.org
Message-ID: <2d6b476a-7f0b-5418-aaae-eea0ed362924@apache.org>


On 17/08/2020 21:38, Steve Sarsfield wrote:
> Yes, AnzoGraph DB does 2.
> 
> Re 1: Against restricting the RDF* spec to SA. Not sure why you'd do 
> that with many vendors in support of PG.  For us, the train of thought 
> is about building a bridge to the Neo4J users of the world, potentially 
> sharing ecosystems, tools, etc.

1 is "Implement <<>> in the object position"

It's in the RDF* paper - it's not about SA or PG - both have it.

(IIRC the argument is "why not"? - one can imagine a ":relatesTo" 
connection of two triple terms but whether that is a real use case, I 
don't know.)

LPG systems have attributes on relationships. (nearest RDF? 
property-literals ?).

     Andy

> 
> 
> *Steve Sarsfield
> AnzoGraph DB*
> 
> 
> On Mon, Aug 17, 2020 at 1:22 PM Pavel Klinov <pavel@stardog.com 
> <mailto:pavel@stardog.com>> wrote:
> 
>     Stardog does (2). Re: (1), it seems orthogonal to the SA vs PG
>     discussion. We can see ourselves supporting that (as well as
>     nesting) if there's demand, we don't expect any technical challenges
>     there.
> 
>     Cheers,
>     Pavel
> 
>     On Mon, Aug 17, 2020 at 7:02 PM Andy Seaborne <andy@apache.org
>     <mailto:andy@apache.org>> wrote:
> 
> 
> 
>         On 15/08/2020 17:15, thomas lörtsch wrote:
>          > Thanks for all responses, corrections and additions and an
>         accordingly updated list:
>          >
>          >
>          >    SA  PG  Implementation  Notes - Documentation
>          >
>          >        +   AllegroGraph    in the works -
>         https://lists.w3.org/Archives/Public/public-rdf-star/2020Aug/0021.html
>          >        x   AnzoGraph
>         https://docs.cambridgesemantics.com/anzograph/v2.2/userdoc/lpgs.htm?Highlight=rdf
>          >        x   BlazeGraph
>         https://github.com/blazegraph/database/wiki/Reification_Done_Right
>          >    x       GraphDB
>         http://graphdb.ontotext.com/documentation/9.2/free/devhub/rdf-sparql-star.html
>          >    x       Jena https://jena.apache.org/documentation/rdfstar/
>          >    +   +   N3              deferred -
>         https://github.com/w3c/N3/issues/27#issuecomment-644768502
>          >    x       rdf4j
>         https://rdf4j.org/documentation/programming/rdfstar/
>          >    x   +   rdfjs/N3.js     PG may become configurable soon -
>         https://github.com/rdfjs/data-model-spec/pull/165
>          >    x   x   RubyRDF
>         http://rdf.greggkellogg.net/yard/file.rdf-README.html#rdf-rdfstar
>          >        x   Stardog https://www.stardog.com/docs/#_edge_properties
>          >
>          >
>          >
>          > I see a tendency towards PG mode. Comments from SA
>         implementers suggested that they chose this approach also
>         because going from SA to PG is easier than the other way round.
>         Also some PG implementers don’t seem to be particularily
>         enthused about SA mode.
> 
>         Great survey!
> 
>         Of the PG systems, how many:
> 
>         (1) Implement <<>> in the object position
>         (2) Provide cascading deletion
> 
>         in their current releases?
> 
>               Andy
> 
>          >
>          > Thomas
> 
> 
>          >
>          >
>          >> On 10. Aug 2020, at 21:41, Steve Sarsfield
>         <steve.sarsfield@cambridgesemantics.com
>         <mailto:steve.sarsfield@cambridgesemantics.com>> wrote:
>          >>
>          >> Confirming that for AnzoGraph DB, this chart is correct. We
>         support the property graph style. We don’t currently have any
>         product roadmap planned for separate assertions.
>          >>
>          >>
>          >>
>          >> Steve Sarsfield, AnzoGraph DB
>          >>
>          >>
>          >>
>          >>
>          >>
>          >
>          >
> 
Received on Tuesday, 18 August 2020 18:00:57 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 18 August 2020 18:00:58 UTC