integer JSON value should be expanded to an IRI in presence of a base IRI

[jmvanel]

Point 8 in IRI Expansion
https://www.w3.org/TR/json-ld11-api/#iri-expansion
says nothing about an integer JSON value that is expanded to an IRI in presence of a base IRI .
So this should be allowed, but the JSON-LD engines I know do not process an integer JSON value in this way.

I already made this issue, with an example:
json-ld/json-ld.org#742

[pchampin]

IRI Expansion says nothing about it because, as far as I can tell, it should never be invoked with a value that is not as string.

The test is usually performed before invoking IRI Expansion, raising different error codes depending on the context. E.g.:

• Create Term Definition, step 14.2.1 https://www.w3.org/TR/json-ld11-api/#ctd-id-not-null

• Expansion, step 13.4.3.1 https://www.w3.org/TR/json-ld11-api/#alg-expand-each-key-value

[jmvanel]

Indeed, it is forbidden by the specification.

However, I can see no reason for not changing the phase
is not a string
with
is not a string or integer
in these steps 13.4.3.1 and 14.2.1 .

What was the reason to exclude integers ?
Was it a bad case of copy and paste in the writing ?
Indeed some cases like language demand strings.

This is a frequent case in JSON data id's . And often it is not possible to change one JSON API .

[gkellogg]

What was the reason to exclude integers ?
Was it a bad case of copy and paste in the writing ?
Indeed some cases like language demand strings.

This goes back to 1.0, and if you look at RFC3987/6 URIs/IRIs are defined based on strings.

I think it's reasonable to change the expansion algorithm to work over primitive types, which would include string, number and boolean. Note that null is filtered wherever it is seen, so would not be feasible (or useful, IMH). Boolean values aren't too useful either, but better to include for regularity.

[jmvanel]

Yes for regularity! Floating point numbers (included in numbers) also can have usage as @id .

I also looked at Editor's Draft , and reviewed all occurrences of "not a string" (14 ! ) .
There at 13.4.10.1 , I suspect that also the string restriction can be removed. But I don't know enough JSON-LD to tell.

Anyway, for next step, am I encouraged to make a pull request on https://github.com/w3c/json-ld-api/pulls/ ?

[iherman]

@jmvanel just an admin comment: at this point, the JSON-LD API is a Recommendation, meaning that it cannot be changed right away without further ado. A PR would be very welcome but, process-wise, what should be done now is to see if it can be listed as a formal Erratum (this is something the CG/WG has to decide, @gkellogg @BigBlueHat) and, at some point, all these should be collected to issue a new version of the spec.

[jmvanel]

This goes back to 1.0, and if you look at RFC3987/6 URIs/IRIs are defined based on strings.

the updated recommendation should maybe say that integer and no base URI is an error, but I guess that there is always a base URI (?) .

[jmvanel]

@jmvanel ... process-wise, what should be done now is to see if it can be listed as a formal Erratum (this is something the CG/WG has to decide, @gkellogg @BigBlueHat) and, at some point, all these should be collected to issue a new version of the spec.

Yes, an Erratum would be cool; these is none at the moment .

I see that there no definition of literal in
https://infra.spec.whatwg.org/#primitive-data-types
but a link to RDF recommendation for literal should be OK for "string or number or boolean but not null" .

[pchampin]

Accepting non-strings as relative IRIs would cause problem when compacting, because it would not be able to round trip. Consider this example. How would you decide that the compacted @id must be a number rather than a string?

I see that there no definition of literal in
https://infra.spec.whatwg.org/#primitive-data-types
but a link to RDF recommendation for literal should be OK for "string or number or boolean but not null" .

Literal is an RDF notion, so it is only natural that the INFRA spec does not define it. But RDF literals go beyond "string or number of boolean" (they can have arbitrary datatypes).

[jmvanel]

Replying to @pchampin , 2 things

Round-tripping not in requirements

The point is, there is no official requirements for JSON-LD. Using a search engine with json-ld requirements site:w3.org , I found this "Unofficial Draft 30 July 2014" :
https://dvcs.w3.org/hg/json-ld/raw-file/default/requirements/latest/index.html
which is not referenced in json-ld11 normative-references
While strict round-tripping is desirable, especially for testing purposes, I feel that it is in this case not possible given the gap too large between data models, namely the absence of global URL / URI / IRI identifiers in JSON specification.

Un-strict round-tripping already admitted in the API Recommendation

See paragraph 8.6 Data Round Tripping
When the default useNativeTypes = false is applied, floating point rounding errors may occur.
This is another example where strict round-tripping does not occur.

[gkellogg]

Round-tripping through RDF does impose some restrictions, but the general intent is to allow round-tripping between Expanded and Compacted modes. I think there is another case where we were not able to do this, and we have to way the desirability of a feature against the inability to round-trip. That certainly could be the case here, if there's sufficient support for this change.

[gkellogg]

Looking at this again, i think it's inappropriate to consider this an Erratum, as it is not an error in the spec, rather an enhancement request to be considered in a future update. It is certainly in the class of "minor", but substantive, updates that might go in to an updated spec. Consequently, I'm changing the labeling (subject, of course, to further WG review).