shexSpec / shex

ShEx language issues, including new features for e.g. ShEx2.1
25 stars 8 forks source link

"max": "*" in ShExJ interpreted as xsd:integer #40

Closed gkellogg closed 7 years ago

gkellogg commented 7 years ago

Consider cardPlus.json:

{
  "@context": "https://shexspec.github.io/context.jsonld",
  "type": "Schema",
  "shapes": [
    {
      "id": "http://a.example/S1",
      "type": "Shape",
      "expression": {
        "type": "TripleConstraint",
        "predicate": "http://a.example/p1",
        "min": 1,
        "max": "*"
      }
    }
  ]
}

Because the definition for "max" in context.json is "max": {"@id": "shex:max", "@type": "xsd:integer"}, this implies that "max": "*" is turned into <http://shex.io/ns/shex#max> "*"^^xsd:integer, which is invalid.

Previously, I believe we did not set @type on "max", and relied on the fact that "max": 1 is interpreted as <http://shex.io/ns/shex#max> "1"^^xsd:integer from a JSON-LD processor. We should consider if we want to go back to this, or do something else for "*", possibly render it as an IRI.

jimkont commented 7 years ago

+1 for an IRI, there was also a short discussion on this here https://gitter.im/shapeExpressions/Lobby?at=587c83b0074f7be763d7b3ef

ericprud commented 7 years ago

I'm happy to do something more rigorous if JSON-LD will support it without requiring a different attribute for natural numbers vs infinity (currently written "*"). Can an @context support "max":3 and "max":"INF" (where sx:INF means infinity)?

gkellogg commented 7 years ago

Yes, if INF is defined as a term, and @type: @vocab, then both "max": "INF" and "max": 1 will expand as expected. Key is that numeric values will always expand to integer/double, depending on if a decimal point is needed, and @type: @vocab will otherwise do a vocabulary-relative expansion.

I can update the context accordingly, but we should decide what INF should expand to.

gkellogg commented 7 years ago

I defined INF as shex:INF, which is the sole instance of the class shex:Cardinality.

gkellogg commented 7 years ago

Fixed by https://github.com/shexSpec/shexspec.github.io/commit/438072ef278b13410485054901dd37c7b0e30da1.

labra commented 7 years ago

I like using a IRI for "*", although I would prefer a more meaningful name than "shex:INF".

In XML Schema the name chosen is "unbounded", could we use "shex:Unbounded" which is more meaningful ?

Also, in shex.shexc, the lines of the form:

shex:max (xsd:integer OR @ rdfs:Resource) ;

look strange because there is no shape rdfs:Resource, should it be nonLiteral ? or maybe, the following?

shex:max (xsd:integer OR [shex:INF] ) ;
gkellogg commented 7 years ago

Lets get a consensus, and I'll change.

Regarding range, it needs to be a class, not an instance, so shex:Cardinality would work.

ericprud commented 7 years ago

I proposed "INF" because I'd just been working with numeric values and XML Schema uses "INF" to represent infinity. It would be really cool integers included "INF" because then max cardinalities would universally be integers. Unfortunately, only float and double have ±∞ so no super coolness.

Ignoring the precedent of XML Schema, I'd say that saying the maximum cardinality is infinity makes sense. But since XML Schema sets the precedent, I'm happy to use sx:Unbounded. It's trivial for me to change it to whatever string we choose.

labra commented 7 years ago

I suggested sx:Unbounded because of the XML Schema precedent and because I think it is more readable than sx:INF. sx:Infinity is also more readable.

Some reasons against sx:INF is that it sounds more mathematical than necessary and it also looks like an acronym, anyway, I would not oppose to keep it you think it is better.

One further doubt, should it be in lower case as sx:literal or sx:iri?

gkellogg commented 7 years ago

Closed with https://github.com/shexSpec/shexspec.github.io/commit/d67e017ce72deca83124e8a619f3cc6664e4604e.