Open JervenBolleman opened 1 year ago
@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 N@ShExR.shex#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?
@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.
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.
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.