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:

• one-to-many language tagged strings, but
• at most one value per language tag.

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:

2.1

{
  "type": "Schema",
  "shapes": [
    { "type": "Shape",
      "id": "Human",
      "expression": {
        "type": "TripleConstraint",
        "predicate": "http://example.org/name"
      } }
  ]
}

The new ShExJ would look like:

2.2

{
  "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:

• neigh(G, n) is the neighbourhood of the node n in the graph G.
  neigh(G, n) = arcsOut(G, n) ∪ arcsIn(G, n).

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 or satisfiesDescendant(…) 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).

• A man-in-the middle attack could cause different systems to receive different documents at different times.
• Accessing the remote resource presents an opportunity to track usage and leak intention.
• Routinely accessing remote resources can place a burden on the host (e.g., schema.org)
• There is no facility for embedded use to avoid the remote lookup.
• A malicious service can cause a stack-overflow by automatically creating nested documents.

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:

• SA Style Manual issues,
• potential copyright or commercial terms [LGTM: ericP],
• IEEE standards word usage(e.g. Shall, Should, or May) [ericP: 2112 keywords probably not needed; conformance clauses still needed],
• specifically-requested issues [ericP: none to date].

Checklist

1. Labeling: Is the draft properly labeled? For example, IEEE P1234/D1, Jan 20XX, Draft Standard for…
2. Copyright: Does the first page include the copyright statement? Do all pages include the copyright footer with the current year?
3. Introduction: Has an introduction been prepared, giving the history of the standard and a description of its purpose?
4. Overall completeness and quality: Is the draft complete, legible, and free of comments and tracked changes? Are pages, figures, and tables numbered consecutively?
5. Figures: Are figures legible? *Avoid the use of color alone to convey meaning.
6. Normative references: Are the references cited in normative text so that it is clear that the reference is required to implement the standard? Non-normative references shall be placed in an informative annex entitled “Bibliography.” Other considerations include the following:
   • The reference is publicly available at reasonable cost
   • If draft standards are included, they shall be marked as drafts (draft number and date)
   • If non-standard documents are included, the citation shall include the date of publication
   • In-text citations shall match the normative reference in Clause 2
   • References to specific parts of other documents shall include the date/edition
   • The normatively referenced material in the document meets the restrictions on commercial terms (see 6.2.2 of the IEEE SA Standards Board Operations Manual)
7. Cross-referencing: Are all figures, tables, equations, and annexes called out in text?
8. Definitions: Are the definitions properly constructed? Are sources cited in parentheses after the definitions? Did you use terms and definitions from the IEEE Standards Dictionary Online instead of creating new definitions or slightly modifying existing definitions?
9. Verb usage: Are the verb choices (shall, should, or may) generally appropriate for the type of document (standard, recommended practice, or guide)?
10. Permissions/copyright: Does the draft contain borrowed material (e.g., text, tables, figures) from previously published material (other than IEEE)? If so, letters of permission must be sent to [email protected] before the start of the IEEE SA ballot. Sample IEEE Permission Form Request and Response Letters (404) for working groups are available for download.
11. Units: Metric units shall be provided, and inch-pound data may be included parenthetically to the metric unit. Exceptions are allowed per IEEE SASB Implementation Plan.
12. Mathematical expressions: Are variables in italics, while constants set in roman? Are variables defined in an equation variable list following each equation?
13. Amendments or Corrigenda: If the draft is an amendment or corrigendum, are instructions on changes to the existing standard clearly shown and explained? If not, please simplify the instructions.

—— source

There are several examples in 5.6.4 Negation Requirement where the JSON and the ShExC versions appear to differ, including

{ "id": "http://schema.example/#S",
  "type": "ShapeNot",
  "shapeExpr": "http://schema.example/#T" }

vs

ex:S NOT @ex:T AND @ex:U

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 . }