Please see the html version.
The ShEx specification is developed here on the gh-pages branch.
Editors Draft: https://shexspec.github.io/spec/ Latest published version: http://shex.io/shex-semantics/
Publishing Snapshots:
ShEx specification
Home Page: https://shexspec.github.io/spec/
License: Other
Please see the html version.
The ShEx specification is developed here on the gh-pages branch.
Editors Draft: https://shexspec.github.io/spec/ Latest published version: http://shex.io/shex-semantics/
Publishing Snapshots:
The test
https://github.com/shexSpec/shexTest/blob/master/negativeStructure/1focusRefANDSelfdot.shex
is syntactically valid according to the ShEx 2.0 spec.
When I define a close shape like
<ShapeExample> CLOSED {
a [ex:TypeA] ;
ex:prop1 xsd:String
}
I can define it as closed, however if define something like
<ShapeExample> CLOSED {
ex:prop1 xsd:String
} AND
{
{
a [ex:TypeA] ;
}
OR
{
a [ex:SubTypeA] ;
ex:prop2 xsd:String;
}
}
Then the closed statement will fail as the there will be extra properties as seen from the shape:
<ShapeExample> CLOSED {
ex:prop1 xsd:String;
}
The documentation on http://shex.io/shex-semantics/#term-CODE isn't clear, in that the production isn't an IRI. (Ask @ericprud for further details)
The CG page now has a blog post with Monday's announcement. Somewhat confusingly, however, the first thing a visitor sees, in large font and boldface:
No Reports Yet Published
Learn more about publishing.
Chairs, when logged in, may publish draft and final reports. Please see report requirements.
Since drafts are also considered "published", could (should) this page be edited to list the deliverables published on Monday?
During a workshop on Distrbuted Knowledge Graph metadata, the need emerged to constrain a property to contain:
Therefore this would be allowed
<> dct:description "My Knowledge Graph"@en, "Mon graphe de connaissances"@fr.
would be valid, but
<> dct:description "My Knowledge Graph"@en, "My KG"@en.
would not.
Is it possible to express that kind of constraint using ShEx?
Does NOT include all IEEE front matter
In the very first line of the Turtle file published at https://www.w3.org/ns/shex.ttl we find:
@prefix dc: <http;//purl.org/dc/terms/> .
Note the ;
after http
. This ends up really bad when parsing it.
As noted in https://lists.w3.org/Archives/Public/public-shex/2021Aug/0000.html.
The ShExC grammar for importDecl is single-valued, but IMPORT EXAMPLE 2 - CIRCULAR IMPORT is multi-valued. Presumably, the example should use two separate IMPORT statements.
In ShExC [49] the language says If "." matches and exclusion matches ...
, but none of the productions include a full stop token.
@ericprud says:
exclusion should include a '.' a al:
[50] exclusion ::= '.' '-' (iri | literal | LANGTAG) '~'?
One feature that will be useful for ShEx is to have top-level shape definitions which refer to other shapes. For example:
<Human> @<Person>
<Person> { :name . }
This change would imply to add more ceremony to the ShExJ. For example:
{ "type": "Schema",
"shapes": [
{ "type": "ShapeDecl", "id": "Human",
"shapeExpr": {
"type": "Shape",
"expression": {
"type": "TripleConstraint",
"predicate": "http://example.org/name" } } },
{ "type": "ShapeDecl", "id": "Person",
"shapeExpr": "Human" }
]
}
The changes for the ShExJ would look like:
The old ShExJ would represent it like this:
{
"type": "Schema",
"shapes": [
{ "type": "Shape",
"id": "Human",
"expression": {
"type": "TripleConstraint",
"predicate": "http://example.org/name"
} }
]
}
The new ShExJ would look like:
{
"type": "Schema",
"shapes": [
{ "type": "ShapeDecl",
"id": "Human",
"shapeExpr": {
"type": "Shape",
"expression": {
"type": "TripleConstraint",
"predicate": "http://example.org/name"
} } }
]
}
This is related with this PR: shexSpec/shexTest#49
In order to kepp backwards compatibility we may allow the old ShExJ in version 2.2 marking it as deprecated and adding it as an annex.
Section 2.1 currently says:
ShEx data structures are represented as JSON objects with a member with the name "type" (i.e. an object with a type attribute):
{ "type": "typeName", member0…n } ↑
And Section 5.4 defines:
ObjectLiteral { value:STRING language:STRING? type:STRING? } ↑
Is there a conflict between type
and type
?
Up top in Terminology we have:
5.3.2 has:
For a node n of the graph G, we define neigh(n) as the set of triples adjacent to n in the graph; these are the triples that have n either as subject or as object.
It's not clear to me why the spec states that ShExC is intended for human readability vs. ShExJ but then proceeds to use ShExJ for the human-readable spec. I appreciate the Primer provides an option to switch between the two formats. It could be helpful for the spec to have this option or to use ShExC exclusively.
If this is desired and there is some effort involved I would like to make the conversion as part of learning more about ShEx.
In ShEx it doesn't seem possible to define a shape expression for a circular reference in data. For example, consider the following data about people and dogs:
Bob owns Fido
Fido likes Jane
Jane owns Spot
Spot likes Jane
I could define a shape for a person who owns a dog that likes a person. However it doesn't seem possible to define a shape for a person who owns dog that likes them. In the example, this would include Jane but not Bob. I'm new to ShEx; maybe I'm missing something. Is there any way for ShEx to define these shapes?
In the JSON-LD version of the spec at https://www.w3.org/ns/shex.jsonld there is no prefix defined for dc
and owl
but they are both used within the document. So parsing it as RDF does not work properly.
1.5.2 Validation Definition says:
n@sl EXACTLY ::- satisfies(n, def(s.label), G, Sch, completeTyping(G, Sch), neigh(n))
n@sl ::- satisfiesDescendant(n, def(s.label), G, Sch, completeTyping(G, Sch), neigh(n))
where I understand completeTyping()
to be making sure that the same total truth is maintained regardless of which pieces of it you interrogate with isValid queries.
The same section then defines a correct typing:
A correct typing is a typing such that for every RDF node/shape pair (n,l),
satisfies(…)
holds orsatisfiesDescendant(…)
holds.
Should the correct typing be ONLY satisfies(…)
? This would allow it to answer shapemaps where EXACTLY is true.
I'm guessing that the current text (post-review by Iovka and Labra) is fine because we're counting on the first two lines of this issue text to differentiate EXACTLY from, um, not EXACTLY. Just wanted your eyes to verify this.
As noted in https://lists.w3.org/Archives/Public/public-shex/2021Aug/0001.html:
In ShEx 2.0, the productions were defined as follows:
[49] valueSetValue ::= iriRange | literalRange | languageRange | '.' exclusion+
[50] exclusion ::= '-' (iri | literal | LANGTAG) '~'?
In ShEx 2.1, they were updated to the following:
[49] valueSetValue ::= iriRange | literalRange | languageRange | exclusion+
[50] exclusion ::= '.' '-' (iri | literal | LANGTAG) '~’?
But, the note on [49] still notes "If "." matches and exclusion matches one or more times”, and that doesn’t make sense in this context. Also, the third ValuesConstraint example has a ‘.’ only at the beginning:
ex:EmployeeShape {
foaf:mbox [ . - <mailto:engineering->~ - <mailto:sales->~ ]
}
Looks like the changes were made in error? Certainly, the new grammar is not forward-compatible with 2.0.
satisfies2
is the second satisfies
function; it has two parameters, and it is only used for NodeConstraints.
pro: satisfiesNC
might read better
con: adds noise to the diff between 2.1 and 2.2.
In the Primer, negative triple constraints are illustrated with:
my:SolitaryIssueShape {
ex:state [ex:unassigned ex:assigned];
ex:component . {0} ;
^ex:component . {0}
}
Why the dot?
Omitting the dot throws an error, even though the ShExJ translation (nota bene, marked as "TODO" when ShExJ is selected in the Primer), as per rdfshape.weso.es/shexConvert:
PREFIX ex: <http://example.org/>
ex:SolitaryIssueShape {
ex:component . {0} ;
}
translates to:
{
"type" : "Schema",
"@context" : "http://www.w3.org/ns/shex.jsonld",
"shapes" : [
{
"type" : "Shape",
"id" : "http://example.org/SolitaryIssueShape",
"expression" : {
"type" : "TripleConstraint",
"predicate" : "http://example.org/component",
"min" : 0,
"max" : 0
}
}
]
}
with nothing obvious requiring .
as a placeholder.
The import feature creates vulnerabilities similar to the JSON-LD remote context loading. In the case of JSON-LD, the document loader provides a means of avoiding accessing remote resources, although it's still come under a fair amount of criticism (See w3c/json-ld-syntax#108 and w3c/json-ld-api#14 for example).
The spec should address this concern and/or provide mitigations. One area that JSON-LD may pursue in the future is the use of integrity checks (ala https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity).
The second (indirect self reference) and third (negated indirect self reference) examples for "5.6.4 Negation Requirement" are exactly the same (except for naming of the shapes and predicates). In the released version, only the ShExJ version of the "indirect self reference" is wrong, in the editor preview both ShExJ and ShExC of the second example include a NOT.
MEC review allows IEEE SA editors to look for:
—— source
The grammars from the https://github.com/shexSpec/grammar repo don't include this production at all, so I assume it can be removed here. If you confirm, I can create a PR.
The ShEx semantics appears to go into a loop on
Schema S = :sl { :p @:sl }
ShapeMap m = { ( :x, :sl ) }
Graph G = { :x :p :x . }
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.