Model is defined in terms of IRIs; Protocol with URI

[azaroth42]

Should update the protocol to use IRI instead of URI. This results in changing the prefer header from oa:PreferContainedURIs to oa:PreferContainedIRIs.

These two values should be described in the Vocabulary, in the same way that oa:annotationService is.

[iherman]

On 23 May 2016, at 21:46, Rob Sanderson notifications@github.com wrote:

Should update the protocol to use IRI instead of URI. This results in changing the prefer header from oa:PreferContainedURIs to oa:PreferContainedIRIs.

These two values should be described in the Vocabulary, in the same way that oa:annotationService is.

Consistency demands +1. I am not sure what the effects would be on implementations, maybe something to call out at CR?

[halindrome]

I hate to bring this up, but the term IRI is really deprecated in the industry. The WhatWG has successfully managed to convince many people that a URL is what we need to talk about, and that the way browsers treat URLs is the real definition... so if we want people to grok this who are NOT standards geeks, we should probably just use URL in names.

[azaroth42]

We resolved to use IRIs for the model here:
#183 (comment)

The important thing being that comparisons between IRIs are defined more clearly than comparisons between "URL"s.

[halindrome]

Oh - I understand and agree that processing should be done using IRIs. I was just reacting to the name in the ontology. Regardless.... if we are standardizing on IRI, and I think we should be, there is some nice language in RDFa Core that we could roll in:

RDFa is a way of expressing RDF-style relationships using simple attributes in existing markup languages such as HTML. RDF is fully internationalized, and permits the use of Internationalized Resource Identifiers, or IRIs. You will see the term 'IRI' used throughout this specification. Even if you are not familiar with the term IRI, you probably have seen the term 'URI' or 'URL'. IRIs are an extension of URIs that permits the use of characters outside those of plain ASCII. RDF allows the use of these characters, and so does RDFa. This specification has been careful to use the correct term, IRI, to make it clear that this is the case.

[iherman]

Adding this texts to, or similar, might indeed be a good idea...

Ivan

P.S. I didn't even remember this text from the RDFa spec...

---

Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)

On 26 May 2016, at 18:44, Shane McCarron notifications@github.com wrote:

Oh - I understand and agree that processing should be done using IRIs. I was just reacting to the name in the ontology. Regardless.... if we are standardizing on IRI, and I think we should be, there is some nice language in RDFa Core that we could roll in:

RDFa is a way of expressing RDF-style relationships using simple attributes in existing markup languages such as HTML. RDF is fully internationalized, and permits the use of Internationalized Resource Identifiers, or IRIs. You will see the term 'IRI' used throughout this specification. Even if you are not familiar with the term IRI, you probably have seen the term 'URI' or 'URL'. IRIs are an extension of URIs that permits the use of characters outside those of plain ASCII. RDF allows the use of these characters, and so does RDFa. This specification has been careful to use the correct term, IRI, to make it clear that this is the case.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[akuckartz]

A "Living Standard" by the WHATWG which seems to be relevant for this issue: https://url.spec.whatwg.org/

It states as one goal:

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone.

[iherman]

My problem is not URL vs. URI. Frankly, I do not care too much about that, and I am happy to ditch URI in favour of URL.

However, the problem seems to be IRI. At the moment, https://url.spec.whatwg.org/ has a reference to the IRI spec[1] but only as part of the stated goals. I do not see the URL parsing (in the WhatWG document) also taking care of IRI-s. If I am proven wrong then, personally, I do not have any objection using URL-s, acknowledging the fact that the latest HTML draft, for example, refers to the What WG document normatively. But if IRI-s are not (yet) part of the WhatWG spec then I think we would have a problem.

Cc: @r12a @duerst

[1] M. Duerst; M. Suignard. Internationalized Resource Identifiers (IRIs). January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987

[r12a]

(this is not an i18n WG response) The i18n WG actually discussed this some time ago and concluded that the web annotation spec doesn't imply any particular processing of resource identifiers that could be called IRIs/URLs that would involve things like punycode and percent-escaping. Rather, we concluded that those processes would be run by implementations using the model, and that the name was chosen simply to indicate (per the RDFa explanation quoted above) that the resource identifiers permit the use of characters outside those of plain ASCII. If those assumptions are correct, and as long as the spec states that resource identifiers permit the use of characters outside those of plain ASCII, I don't think we were overly concerned about what you call them.

[akuckartz]

How was this resolved?

[azaroth42]

The protocol is defined in terms of IRIs, following the decision from Model. We renamed the preference to use IRI instead of URI, and changed all the text references to IRI from URI.