More later, just a quick note re: > (ajs6f: Does JSON-LD 1.1 say anything about this?)
Nope, not a thing. If anything, the direction has been in the other direction. E.g. 1.0 allows bnodes-as-predicates and we strongly discourage that in 1.1-- pushing folks towards "vanilla" RDF. Our next WG meeting is this Friday, and I am happy to raise any questions we want raised, then or going forward. Adam On Mon, Apr 6, 2020, 4:10 PM Andy Seaborne <a...@apache.org> wrote: > WIP > > RDF* is adding triples-as-term to RDF so that you can annotate triples. > This is not reification. > > Summary: > > * Aim to get it working for Turtle*, in-memory, SPARQL* and JSON results > (Fuseki in other words). > * "sometime" > * This is not by converting to reification and back again! > * Experimental - may change without warning. > > --------------------------------- > > Details of RDF* > > > https://blog.liu.se/olafhartig/2019/01/10/position-statement-rdf-star-and-sparql-star/ > https://arxiv.org/pdf/1406.3399.pdf > > ---- Example ---- > PREFIX : <http://example/> > > :s :p 123 . > <<:s :p 123>> :q 678 . > ---- > > The RDF Triple term is <<:s :p 123>>. > > (it is lucky that early versions of SPARQL, pre 1.0, had <<>> for > reification ... so the grammar works!) > > Currently working: > Node_Triple > Turtle* parsing > Turtle* writing > In-memory storage > SPARQL syntax > SPARQL execution with <<?s ?p ?o>> pattern matching. > SPARQL text format output of result sets. > Conversion to/from reification > > (it is lucky that early ideas for SPARQL, pre 1.0, had <<>> for > reification ... so the grammar works!) > > including nested cases (yup: triple terms inside triple terms is legal: > <<:s :p <<:s :p 123>> >> is legal). > > There are other areas impacted: > Model API > Result sets (JSON, XML) > JSON-LD > RDF/XML syntax > > and there is less degrees of freedom in design for compatibility reasons. > > Ideas: > > 1. API: > > RDF Triple terms can be in the subject position, so it is a Resource, > even though they are really abstractly literals. > > Going through this list, 1.3 is my first choice at the moment. > > 1.1. Encoding > > Have special blank nodes or URI that carry the triple encoding information. > > Having some encoding as a fallback mechanism is probably wise. It is > needed for RDF/XML, and may be N-triples. > > 1.2. Resource-Statement -- built-in > > To avoid a signature change, I think we can put it in Resource with > "Resource::isTriple()" and "getTriple() -> Statement" with the goal of > "no RDF* -> no impact". > > 1.3. Resource-Statement -- as(Statement.class) > > A case of Resource that is not a blank node nor a URI but can be used > with RDFNode.as(Statement.class) to get the Statement. or even a blank > node, that RDFNode.canAs(Statement.class) - sort of on the fly reification. > > 1.4. New RDFNode subclass. > > The ultimate "do it properly" - add a new kind of RDFNode - is an API > change as the subject position changes. I don't see any compatibility > path. Only consider when it is clear what a stable answer is. > > 2. Result sets > > I favour 2.1, together with switchable to "encoding", so that foreign, > plain-RDF, code does work on SPARQL* results to some degree. That > includes YASGUI. > > 2.1. "Do it properly" > New term type: > { "type": "triple" , "value": } > and "value" is a JSON object > {"subject": ... , "predicate": "object": } > > XML results is similar .. which is TriX format !!!! > <triple> > <uri></uri> > <uri></uri> > <typedLiteral > datatype="http://www.w3.org/2001/XMLSchema#integer";>123</typedLiteral> > </triple> > > 2.2. An "Encoding" approach: > > { "type": "triple" , "value": "_encoding_" } > and/or > { "type": "uri" , "value": "encoding" } > > > 3. RDF/XML > > Unlike Turtle* changing the syntax is impractical. > Doing nothing is quite reasonable and wait to see what common practice > emerges. Encoding works. > > 4. JSON-LD > > Encoding is probably the way to go. > (ajs6f: Does JSON-LD 1.1 say anything about this?) > > > Term encoding: > > It's going to be long! Prefixes can't be assumed to be present. It needs > 3 components, and maybe a datatype or language. And so we need a > separator/encoding of use of the separator. > > Andy >
