On 06/04/2020 22:28, [email protected] wrote:
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.
No need from my POV. RDF* isn't a standard and details of it aren't
clear, to the point where a real WG would probably have opinions.
There is no reason JSON-LD needs to pay attention to it while in CR.
Andy
Adam
On Mon, Apr 6, 2020, 4:10 PM Andy Seaborne <[email protected]> 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
