Re: [apps-discuss] how to use non-URI registered identifiers when URIs are needed (for RDF)

To turn a non-URI registered identifier into a URI when you need one, I'd suggest 
using RFC 3553 

 IETF URN Sub-namespace for Registered Protocol Parameters
 http://tools.ietf.org/html/rfc3553


> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of Erik Wilde
> Sent: Thursday, October 11, 2012 1:16 AM
> To: apps-discuss@ietf.org application-layer protocols
> Cc: johnarwe@us.ibm.com
> Subject: [apps-discuss] how to use non-URI registered identifiers when URIs are
> needed (for RDF)
> 
> hello.
> 
> i had an interesting discussion about how it is allowed to refer to
> registered link relation types, and since this may be of interest for
> other non-URI identifiers as well, i thought i raise this as a general
> question. the starting point was john arwe asking whether it would be ok
> to use URIs as link relation type identifiers, which is allowed by RFC
> 4287, but then neither allowed nor specifically disallowed by RFC 5988,
> which updates RFC 4287. john did a great job at digging through the
> history of this, and here is what he found:
> 
> On 2012-10-09 10:34 , John Arwe wrote:
> > It may be that 5988 was attempting to incorporate some aspects of 4287
> > when 5988 took over and expanded the registry.
> > [1] lays out the equivalence and requires it.  Odd to expect people to
> > read Atom in a "superseding" RFC (quotes b/c I realize it's only the
> > registry that 5988 takes over and expands upon).
> > POWDER relies on it too, as recently as 2010 [2]
> > If I infer from the URI that [3] was an antecedent to 5988, it was
> > explicit in the past.  [4] also mentions it, but I infer from [5] that
> > it was dropped as a result of AnneVK's comment.  The TAG was also
> > batting this around in 2008 [6] and apparently affirming it (via POWDER
> > again) in  2012 [7].  RDFa also mentions/uses it.
> > [1] http://tools.ietf.org/html/rfc4287#section-4.2.7.2
> > [2] http://www.w3.org/2007/powder/powder-errata
> > [3] http://tools.ietf.org/id/draft-nottingham-http-link-header-02.xml
> > [4] http://tools.ietf.org/id/draft-nottingham-http-link-header-06.xml
> > [5] http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0547.html
> > [6] http://www.w3.org/2008/10/02-tagmem-minutes
> > [7] http://lists.w3.org/Archives/Public/www-tag/2012Mar/0090.html
> 
> the starting point is the question how RDF scenarios, requiring URIs as
> identifiers, could reuse concepts such as link relation types. in this
> specific example the concrete question is whether RFC 5988, since it
> does not mention URIs as being equivalent to simple string values,
> effectively disallows what RFC 4287 allowed. my guess is that this is
> the case, but maybe it would help to make this more explicit (maybe as
> an erratum to RFC 5988?).
> 
> the bigger question then is: how is RDF supposed to refer to these
> registered values? is that just RDF's problem, being URI-centric when it
> comes to identifiers, or would it make sense to have some kind of best
> practice or method how registered values for the Internet or the Web,
> which very often are not URIs, and the requirement of RDF to have URIs
> as identifiers, can be sorted out.
> 
> i am asking both for guidance about the specific question about RFC
> 4287, as well as for ideas (and maybe even existing experience or
> examples) how to bridge the gap between non-URI identifiers we might
> want to use in application layer protocols, and RDF's requirement to
> have URIs as identifiers.
> 
> thanks and kind regards,
> 
> dret.
> 
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>             | UC Berkeley  -  School of Information (ISchool) |
>             | http://dret.net/netdret http://twitter.com/dret |
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss