Update RDF serialization (ShEx/RDF) #5

labra opened this Issue May 26, 2016 · 6 comments


None yet

3 participants

labra commented May 26, 2016

The first versions of ShEx contained an RDF serialization. However, the documentation in the wiki about RDF serialization looks outdated. We should update that documentation so we could create a compatible RDF serialization of ShEx.

The Wiki documentation about RDF serialization is here

@labra labra referenced this issue in labra/shaclex Nov 24, 2016

Add RDF serialization format for ShEx #8

labra commented Nov 24, 2016

I have created a more specific issue for my Shaclex implementation here.

There are 2 possibilities:

  • Define ShEx vocabulary on top of SHACL, trying to keep compatibility between ShEx properties and SHACL properties
  • Define a new vocabulary for ShEx independently from SHACL, althouh some properties could be duplicated.

For example, in ShEx, we have the ShapeAnd construct. Should we represent it as: sh:and where sh points to the SHACL namespace?

In my opinion, it would be cleaner if we define new properties for ShEx. Although some of them could be duplicated, it is not clear that the semantics of them is really the same, and maintaining those properties in different namespaces would facilitate conversion between ShEx and SHACl schemas.

labra commented Nov 25, 2016

After a meeting with Eric we have decided to do the conversion through JSON-LD and to keep the ShEx namespace.

gkellogg commented Dec 21, 2016 edited

I've done some work on this, creating an RDFS vocabulary, which also has JSON-LD and HTML+RDFa versions, where the JSON-LD also serves as a context. (These are all created using a script, with the source being in a CSV file).

These are currently configured to go at https://shexspec.io/ns/, but that can certainly be changed.

I went through and created JSON-LD versions of all of the examples, which you can find, in my repo: https://github.com/ruby-rdf/shex/tree/develop/examples/jsonld.

Very few changes are needed from the original ShExJ. Basically, the "shapes" values are in an array of objects, where the "id" is the index. (We're actually working on an @id index for JSON-LD 1.1, which would restore the previous shape).

I changed from "shapeExpr" and "shapeExprs" to just using "expression" and "expressions", which seems more consistent. Property values which are RDF literals (e.g., for Annotation object and values objects, use the JSON-LD value object model.

Plural versions of predicates are added as JSON-LD terms, with @container: @list to keep the original order, where that seems important.

I verified that all examples turn into pretty reasonable Turtle serializations.

If people like this, I can do a PR into shexspec.github.io for the namespace files.

labra commented Dec 22, 2016

I like the approach very much.

Although I didn't have time to review all the the details, I think the approach is a good step. About the plural names, it would be nice if we could keep both ShExJ and ShEx-JsonLd synchronized.

Should we change the ShExJ names?


About the plural names, it would be nice if we could keep both ShExJ and ShEx-JsonLd synchronized.

Other than shapeExpr(s), they are aligned right now. Could easily include shapeExpr(s) instead of expression(s), but it's not clear to me, in either ShExJ or ShExR, if there is a semantic distinction. If there is, then fine. Otherwise, I don't see the point.

Another thought was on Inclusion, which references a Shape, but really the first TripleConstraint contained within that shape. In ShExC that could easily be resolved at parse time. In ShExR, it could be the subject of that TripleExpression made explicit. Of course, this would be another incompatibility with ShExJ.

@gkellogg gkellogg modified the milestone: 2.0 Jan 3, 2017

REASON: Resolved by adoption of JSON-LD
PARTICIPANTS: @labra, @gkellogg
RELATED: Change ShExJ to be compatible with JSON-LD for 2.0, ShapeRef and Inclusion redundant in RDF representation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment