Re: [xri] Thoughts on XRD-to-resource cardinality

[Nat Sakimura <n-sakimura@nri.co.jp>]

Comments inline:

--------------------------------------------------
From: "Drummond Reed" <drummond.reed@cordance.net>
Sent: Wednesday, January 28, 2009 2:59 PM
To: "'XRI TC'" <xri@lists.oasis-open.org>
Subject: [xri] Thoughts on XRD-to-resource cardinality

> I will be offline Thursday and Friday travelling to a memorial, so I want 
> to
> contribute here on the list to advance today's discussion about
> XRD-to-resource mapping
> (http://wiki.oasis-open.org/xri/SelfServeAgenda#head-a4044b7035eb441c2674549
> d07ccaf27daed8970).
>
> As I said on the call, the concept of a one-to-many mapping between an XRD
> and the resources it describes is a mind-expander for those of us who have
> been living a one-XRD-to-one-resource worldview for a few years now. But 
> the
> use case -- being able to get and cache one XRD to describe potentially a
> very large number of resources (such as an entire site) is compelling.

Well, as I have stated in my previous mail, this is a well studied area in
the Object Orientation, I suppose, and it still is one-XRD-to-one-resource.
We have just defined a instantiation method by templating.

>
> Under a one-to-many mapping, I believe Eran's right that the concept of
> asserting a synonym (not just CanonicalID but any synonym) pretty much 
> goes
> away. The only synonym assertion I could see providing is some form of
> aliasing template that would apply to the URIs of all the described
> resources (e.g., every that maps to the http://foo.example.com/* template
> can all be mapped to the http://bar.example.com/* template).

I am not sure about this. Think of this example.

<XRD>
   <CanonicalID>https://sakimura.org/nat#12345678</CanonicalID>
   <About>https://google.com/sakimura</About>
   <About>https://id.mixi.jp/nat</About>
   <About>https://marimba.org/webmaster</About>
   <About>https://nri.co.jp/employee/n-sakimura</About>
   <link>
       ....
    </link>
</XRD>

How do you construct a valid template for this example?
(Of course, the above XRD is just stating that owner of the CanonicalID
  allows him to be desribed by the uris in <About>, and not vice-versa.)


>
> But that appears to be of limited use, and probably not appropriate for
> assigning CanonicalIDs (which is usually a mapping from a reassignable to 
> a
> persistent identifier).
>
> But the rest of the XRD metadata and Link metadata still seems 
> appropriate,
> i.e., it applies as much to an individual resource (one-to-one mapping) as
> it does to a group of resources (one-to-many mapping).
>
> So what I'm wondering is if maybe there should be a clear way of 
> indicating
> the cardinality of the XRD. In other words, a child element of the root 
> XRD
> element that indicates whether it is it an individual XRD (one-to-one
> mapping) or a group XRD (one-to-many mapping).
>
> If there was a choice between two mutually exclusive options for that 
> child
> element, then all the other elements that are appropriate only for one or
> the other (CanonicalID, EquivID, URIMap, etc.) could follow as children of
> that element.
>
> Here's a simple example using the element names <Resource> and
> <ResourceGroup>:
>
> INDIVIDUAL XRD:
>
> <XRD>
>    <Expires>2009-01-01T08:30:00Z</Expires>
>    <Resource>
>        <CanonicalID>http://example.com/resource/1</CanonicalID>
>        <EquivID>http://example.net/resource/1</EquivID>
>    </Resource>
>    <Type>http://example.com/type/profile_photo</Type>
>
>    <Link>
>        <URI>http://example.com/resource/2</URI>
>        <Rel>http://example.com/rel/profile</Rel>
>    </Link>
> </XRD>
>
> GROUP XRD:
>
> <XRD>
>    <Expires>2009-01-01T08:30:00Z</Expires>
>    <ResourceGroup>
>        <URIMap>http://example.com/resource/*</URIMap>
>    </ResourceGroup>
>    <Type>http://example.com/type/photos</Type>
>
>    <Link>
>        <URI>http://example.com/service/1</URI>
>        <Rel>http://example.com/rel/some-group-service</Rel>
>    </Link>
> </XRD>
>
> Thoughts?

BTW, is this <Resource> element now semi-official?

>
> =Drummond
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>