[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRD delegated identifer element (was part of: questions about LRDD / OpenID)
> Markus wrote: > > My intuitive answer
would be that the delegate goes into XRD:Link:Alias, but I'm probably not
really > so close to this. Yes, I had been thinking about the
possibility of using “XRD:Link:Alias” as the new name for “XRD:Link:LocalID”
too. But here’s the conceptual problem
with that. As currently proposed in http://wiki.oasis-open.org/xri/XrdOne/XrdSchema,
XRD defines two elements at the XRD level to express identifiers identifying
the resource described by the XRD: 1) XRD:Subject – the canonical URI
for the resource. 2) XRD:Alias – any other synonymous
URI for the resource. The problem with using either of the
element name “Subject” or “Alias” at the XRD:Link level
is that it can lead to semantic confusion about whether the element is
identifying the canonical ID or synonym ID of: a) The resource that is the target of the
link, or b) The resource described by the XRD _as identified in the context of_ the
resource that is the target of the link. The second point is subtle but very
important. As an example, say you have an XRD describing resource A with an
XRD:Link to resource B. Inside this XRD:Link element, there are a total of four
logical options for identifier elements: 1) The canonical URI for resource B (the
target of the link). 2) Any other synonymous URI for resource B. 3) The canonical identifier (which may not
be a URI) for resource A _in the context of
resource B_, i.e., the canonical identifier by which resource B
identifies resource A. 4) Any other synonymous identifier (which may
not be a URI) for resource A _in the context
of resource B_, i.e., any other identifier by which resource B
identifies resource A. Note that (1) is already recognized as a
key use case for XRD 1.0, and that (3) is the well-know delegated identifier
use case for OpenID. (2) and (4) are less compelling use cases, and thus may
not warrant a standard XRD element (but don’t be surprised if they crop
up). So even if we limit our scope to (1) and
(3), that means that we need _two_
child elements of <XRD:Link> that express: * the canonical URI for resource B (the target
of the link), AND * The canonical identifier by which
resource B identifies resource A. That’s the semantics we need to
express as clearly as possible in the element names. In other words, were we to
“spell them out clearly”, these two element names might be: 1) <XRD:Link:Canonical-URI-For-Link-Target-Resource> 2) <XRD:Link:Canonical-URI-For-XRD-Subject-In-Context-Of-Link-Target-Resource> If we agree those are the correct
semantics, we just need to figure out the best short names that capture those
semantics. Here’s one suggestion (but my no means the only one): 1) <XRD:Link:Object> This follows
from RDF semantics. If the RDF subject of an XRD has the element name <XRD:Subject>,
and each RDF predicate on that RDF subject is an <XRD:Link:Rel>, then a
logical name for the RDF object of the link would be <XRD:Link:Object> 2) <XRD:Link:RelativeSubject>
This follows from the above, i.e., if we use “Subject” to mean the
resource described by the XRD, then “Relative Subject” would mean
the same Subject, only as identified relative to the Link Object. Thoughts? =Drummond From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello My intuitive answer would
be that the delegate goes into XRD:Link:Alias, but I'm probably not really so
close to this. On Mon, Mar 23, 2009 at 6:52 PM, Drummond Reed <drummond.reed@cordance.net> wrote: I'm latching onto the
very last question Will put in his response to Markus' |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]