JSON-LD as constraind by grammar is limiting

[JervenBolleman]

There are many ways to write JSON-LD documents that could express Shape Expressions. However, many of these reasonable serializations are not valid ShexJ files. e.g.

{ "@context": 
 	{ "@vocab" : "http://www.w3.org/ns/shex.jsonld", 
      "foaf" : "http://xmlns.com/foaf/0.1/" ,
      "predicate" : {"@type":"@id"}},
  "type": "Schema",
  "shapes": [
    { "@id": "http://my.example/#UserShape",
      "type": "Shape",
      "expression": {
        "type": "TripleConstraint",
        "predicate": "foaf:name",
        "valueExpr": {
          "type": "NodeConstraint",
          "datatype": "http://www.w3.org/2001/XMLSchema#string" } } }
  ] 
}

This is a small adaptation of one of the primer examples but is not a valid ShexJ file.

The example here and the JSON-LD in the primer are equivalent RDF wise.

A solution could be to add a standard JSON-LD framing to generate JSON-LD that fits into the grammar.
Other option is to use ShexR as the basis for defining ShexJ.

Why is this important, it is quite normal to generate some Shex shapes based on the output of some existing RDF dataset, and the fact that we can't directly sparql construct the shapes is unfortunate.

[ericprud]

@gkellogg , have you tried to frame ShExR->ShExJ using JSON-LD 1.1?

@JervenBolleman , I recall it not being quite possible with JSON-LD 1.0 because ShExJ wants e.g. (YAML for terseness):

type: Schema
shapes:
- type: ShapeDecl
  id: http://a.example/Commuter
  shapeExpr:
    type: Shape
    expression:
      type: TripleConstraint
      predicate: http://a.example/rides
      valueExpr: http://a.example/Vehicle
- type: ShapeDecl
  id: http://a.example/Vehicle
  shapeExpr:
    type: Shape
    expression:
      type: TripleConstraint
      predicate: http://www.w3.org/1999/02/22-rdf-syntax-ns#type
      valueExpr:
        type: NodeConstraint
        values:
        - http://a.example/Bike
        - http://a.example/Bicycle
        - http://a.example/Unicycle

and not:

type: Schema
shapes:
- type: ShapeDecl
  id: http://a.example/Commuter
  shapeExpr:
    type: Shape
    expression:
      type: TripleConstraint
      predicate: http://a.example/rides
      valueExpr: http://a.example/Vehicle
      - type: ShapeDecl
        id: http://a.example/Vehicle
        shapeExpr:
          type: Shape
          expression:
            type: TripleConstraint
            predicate: http://www.w3.org/1999/02/22-rdf-syntax-ns#type
            valueExpr:
              type: NodeConstraint
              values:
              - http://a.example/Bike
              - http://a.example/Bicycle
              - http://a.example/Unicycle

which tends to fall out of framing (at least when you have corefs to Vehicle. Gregg used a bit of post-processing to get it the last mile.

So far, we've defined ShExR as ShExJ's JSON-LD interpretation. If we want to specify the return, we need to either specify that post-processing or define it in terms of e.g. JSG with an algorithm that starts with a typed node N, validates it according to [email protected]#schema, and defined ShExR2ShExJ as e.g.:
[[
There is some ShExJ object O such that match(N rdf:type shex:{O.type}) matches 1 triple.
Thee is a JSG object declaration D named O.type.
For each ShExJ property P in D,
if there is some value V such that match(N, shex:{P}, V) matches 1 triple,
O.{P} = ShExR2ShExJ(V)
]]
Something like that would start with the Schema and recursively visit a valid ShExR schema. We'd want special behavior around ShapeDecls to keep them at the top level.

Thoughts?

[gkellogg]

@ericprud IIRC, JSON-LD 1.0 didn't have @id-maps or similar, which meant that you couldn't just re-frame to get back to ShExJ. It may be possible now, but I haven't spent any time on it in a while. Honestly, been pretty swamped with other WGs right now.

That said, you may be interested in YAML-LD, which may have a future as a recommendation.