Re: URI and qcodes - does some one has examples and documentation ?
- Just to be a bad guy: qcodes, unlike CURIES, are not "only" compact URIs; they represent a scheme/code pair, the scheme prefix is associated with a scheme URI and the pair can be inflated as a full URI to be RDF compliant + retrievable.
A good (REST oriented) scheme URI is e.g. http://example.com/people/
A URL like "http://example.com/people?id=12345&group=" makes a very bad scheme URI. Therefore this whole discussion seems out of real life qcode usage scope.
> Conclusion for G2 processors: how to make a QCode out of
> a) Scheme URI: http://example.com/people?id=12345&group=
> b) alias: pers
> c) code: 223
> d) QCode = pers:223
> Resolving the QCode pers:223 back to a URI would make
> http://example.com/people?id=12345&group=223 - as string.
> But: when you compare two URIs - e.g.
> http://example.com/people?id=12345&group=223 with
> http://example.com/people%3Fid=12345%26group=223 all the encoding must be
> applied first and then compared. That's actually what the processing model
- --- In firstname.lastname@example.org, "Michael Steidl \(IPTC\)" <mdirector@...> wrote:
>It's indeed a bit tricky! It works like this: a specific scheme does not have to explicitly list characters with reserved purpose for that scheme. By default, it inherits those from the generic syntax. It can, however, "override" the role of a given character in some its component: in that case it has to state this explicitly. As you remark, RFC 2616 does not mention &, so the generic system applies and therefore & in the query of an http URI must be percent encoded by the producing application if it is not used as a separator but as regular data octet.
> This "reserved purpose" is exactly causing me headaches as I was not able to
> find an *explicit* definition that e.g. & has a purpose which makes it a
> reserved character for the http URI scheme.
> I've emphasized *explicit* as the http RFC 2616 doesn't even mention &, on
> the other hand the URI RFC 3986 includes & into its - potential - reserved
> characters  but says the state of being a reserved character is actually
> defined by the specifications of the different URI schemes. But as just
> said: the specification of the http scheme doesn't even mention the &
> character. So do we have to build on practical experience combined with
> feelings from the guts or written specifications?
What I summarize here is a consequence of various ABNF rules in the generic syntax (RFC 3986), starting with the rule for the query component, and some prose in section 2.2. In particular: "each syntax rule lists the characters allowed within that component (i.e., not delimiting it), and any of those characters that are also in the reserved set are "reserved" for use as subcomponent delimiters within the component" and "URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component."