Loading ...
Sorry, an error occurred while loading the content.

Re: URI and qcodes - does some one has examples and documentation ?

Expand Messages
  • laurent_le_meur
    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
    Message 1 of 35 , Jan 4, 2012
    • 0 Attachment
      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.

      Laurent

      > Conclusion for G2 processors: how to make a QCode out of
      > http://example.com/people?id=12345&group=223
      >
      > 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
    • Philippe Mougin
      ... 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
      Message 35 of 35 , Jan 5, 2012
      • 0 Attachment
        --- In newsml-g2@yahoogroups.com, "Michael Steidl \(IPTC\)" <mdirector@...> wrote:
        >
        > 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 [1] 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?

        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.

        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."

        Philippe
      Your message has been successfully submitted and would be delivered to recipients shortly.