Does data type or language make sense in stems?

[hsolbrig]

IRI, Literal and Language stems are all intended to function as string comparisons -- the string representations of the respective types match when they start with the stem. Currently, the exclusions of IriStemRange and the stem and exclusions of LiteralStem, LiteralStemRange, LanguageStem and LanguageStemRange refrence objectValue, which is defined as IRI|ObjectLiteral

I would argue that language and type make no sense in the context of string comparisons.

Recommendation: objectValue = IRI|ObjectLiteral ; IriStem { stem:IRI } # IriStemRange with exclusions IriStemRange { stem:(IRI|Wildcard) exclusions:[objectValueIRI | IriStem +]? } LiteralStem { stem:ObjectLiteralSTRING } # LiteralStemRange with exclusions LiteralStemRange { stem:(ObjectLiteralSTRING|Wildcard) exclusions:[objectValueSTRING|LiteralStem +]? } LanguageStem { stem:ObjectLiteralLANGTAG } # LanguageStemRange with exclusions LanguageStemRange{ stem:(ObjectLiteralLANGTAG | Wildcard) exclusions:[objectValueLANGTAG | LanguageStem +]? }

LANGTAG : ([a-zA-Z])+ ("-" ([a-zA-Z0-9])+)*

See: https://github.com/shexSpec/shexTest/compare/master...Stem-string for changes to test cases

[ericprud]

I think they don't make sense in stems. I created a branch of shex.js which passes the tests in Harold's comment. Note that this a change to our sort of "Candidate Rec" but I think we should go ahead with it.

[gkellogg]

See https://github.com/shexSpec/shex/issues/54#issuecomment-292019551 for a discussion of why this breaks with JSON-LD in 1.0. I don't think we can do this until we move to JSON-LD 1.1.

[ericprud]

PROPOSED : that datatype stems don't make sense and language stems are covered by the merged Stem-string branche.

Interested: Harold, Gregg, ericP