[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] PILIN docs and Abstract Identifier Architecture paper
Drummond has asked for my thoughts about the AbstractIdentifierArchitecture page. The new draft includes language which address the concern I had expressed to Drummond over the weekend, and Dan Connolly had independently raised at http://lists.w3.org/Archives/Public/www-tag/2008Sep/0083.html --- identifiers are only ever abstract or concrete, as the page defines it, with regard to a given resolution service (or protocol, as the page terms it). Since both HTTP and XRI have one primary resolution method in mind, the constraint is appropriate --- although it makes HTTP go into loops when you do want to resolve to descriptors instead of resources: you clearly can't do so in the same resolution method, as the page concludes. That said, an identifier to us is just an association of a name with a referent; when we start constraining how that identifier resolves, we're no longer talking about identifiers per se --- but resolution requests. Conflating an identifier with a request to resolve an identifier (concretely or abstractly) is always perilous, and I'd keep adding "in the context of a given communications protocol" continuously --- especially as you're switching protocols between XRI and HTTP (even if at a conceptual level, and not a physical transport). I'd just add the caveat that even in a single protocol, there's more than one way to resolve an identifier. For instance, OpenURL takes URIs as parameters, and resolves them differently to what the default resolution is (if any); and XRI crossreferences seem to me to be heading the same way. (For that matter, XRI-through-HTTP is conceptually a different kind of resolution from vanilla HTTP.) So while it may be obvious that =drummand, =drummond(+descriptor), and http://xri.net/=drummond?_xrd_r=application/xrds+xml are not the same identifier, I'd say that explicitly (and include something like =drummond(+descriptor) .) Oh, and with the Handles, I think the examples are misleading. Inasmuch as http://dx.doi.org/10.1000/182 is an HTTP GET, what it gets is the representation, not the descriptor: it is truly a synonym of http://www.doi.org/hb.html . The descriptor of doi:10.1000/182 is in the first instance the Handle record, e.g. http://nascent.nature.com/openhandle/handle?id=10.1000/182&format=rdf&mimetype=application/xml ; if the DOI metadata was exposed as a service, I'd link to that instead, since they're clearly not using Handle to encode their descriptors. (Try http://nascent.nature.com/openhandle/handle?id=10000.2/m.donoghue&format=rdf&mimetype=application/xml for a more heavy-duty Handle-based descriptor --- as opposed to hdl.handle.net/10000.2/m.donoghue , which is a representation. (A lame one, but I don't think Handle have taken descriptors seriously yet.) -- Dr Nick Nicholas, firstname.lastname@example.org Link Affiliates, http://www.opoudjis.net skype:opoudjis Melbourne. "There is a danger, my dear Neophron, that they will go further, and conceive a contempt for the stress-accent as something very trivial, and will decree that any group of words of any kind is a verse." --- Maximos Planudes, predicting free verse and worse, late xiii AD.