IRI-s vs. URL-s

[iherman]

Wonder whether we should not adopt URL-s in the terminology, with the remark that the term encompasses IRI-s like done, eg, in the HTML document reference. This is where developers have gone, and it may be silly to ignore it and continue using the IRI term...

(The same comment applies to the other two documents, too, obviously.)

[gkellogg]

It seems to be the way things are going, although I personally miss the distinction between “Identifier” and “Locator”, which implies dereferencability.

[gkellogg]

Interesting that DOM continues to use URI, at least for baseURI. RDF 1.1 uses IRI, so it may make sense to continue that usage.

[iherman]

I see end users the main targets of this document, which intends to be very didactic (which is good!). Application developers (who would use the DOM) is not really our concern in this respect (besides, baseURI is probably kept for backward compatibility reasons).

Yes, RDF uses IRI, we cannot change that. And it is probably the precise way of saying things. But I do not consider this as a decisive factor...

[azaroth42]

There is a technical difference between IRIs and URIs. In particular, consider this comment: w3c/web-annotation#183 (comment)

The processing model changes to some degree, so we should be careful not to invalidate 1.0 documents unintentionally.

[azaroth42]

In the HTML5 note, there is this caveat:

There are notable differences in the manner in which Web browsers and other software stacks outside the HTML context handle URLs.

Given that JSON-LD is not just for web browsers, before we could accept this change, I think we should determine the extent to which the caveat would make life more difficult. I propose we do not take action on this issue until we can address the concern.

[azaroth42]

PROPOSAL: Defer any change until the extent to which technical differences between URL and IRI can be determined, especially any difference between web browser and other stacks.

[azaroth42]

Proposal above was accepted by the WG, on the call on 2018-09-14. Tagging defer until the above is satisfied.

[krobi64]

Question around this topic: Until we can implement a did method for our framework (https://po.et), I was looking to use https://tools.ietf.org/html/rfc2397 as a way to for our users to anonymously insert identity, specifically for the Ed25519 2018 Signature Verification Key. It seems that you are specifically referencing https and http URL schemes. That is far too limiting.

[BigBlueHat]

@krobi64 that's precisely why many of us would prefer to keep the IRI terminology in use in the spec now: https://www.w3.org/TR/json-ld11/#iris

By that definition data: IRIs/URLs work just fine. Their a bit unusual as standalone identifiers (due to how long they can get), but they certainly work fine as values.

JSON-LD supports any kind of IRI (including URIs, URNs, and URLs) not just https and http URL schemas (however common those might be).

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Close syntax #25 wontfix, we stick with IRI rather than using URL {: #resolution9 .resolution}

View the transcript

URL-s vs. IRI-s
Ivan Herman: #25
Proposed resolution: Close syntax #25 wontfix, we stick with IRI rather than using URL (Rob Sanderson)
Gregg Kellogg: +1
Adam Soroka: +1
Rob Sanderson: +1
Ivan Herman: +1
Harold Solbrig: +1
David Newbury: +1
Simon Steyskal: +1
Benjamin Young: +1
Jeff Mixter: +1
Resolution #9: Close syntax #25 wontfix, we stick with IRI rather than using URL {: #resolution9 .resolution}