Re: [xri] thoughts on linked XRD rel value

[Joseph A Holsten <joseph@josephholsten.com>]

Short version: rdf-style seeAlso doesn't imply enough trust semantics  
for XRD trust

The reason I suggested "seeAlso" is because RDF uses it with almost no  
semantic implication. It merely says: there's another document over  
there that you might be interested in.  In RDF, the seeAlso property  
doesn't assert anything about the authority or subject of the linked  
resource. If that linked resource doesn't speak for itself, the  
seeAlso property doesn't add anything.

I'm not sure what that would mean if an XRD linked via seeAlso didn't  
specify its Subject.

I have never fully grasped the XRD trust model, so I don't feel very  
qualified to express a judgement on documents where the trust must be  
inferred. I know an RDF-style seeAlso is fine if the linked XRD falls  
into an explicit trust model (HTTPS or dSig with a verifiable cert  
inside its authority) and explicitly identifies its Subject. I think  
that this sort of weak seeAlso relation is useful because it only  
points to the other XRD without implying trust.

Of course, it sounds like XRD trust chains need more than that. I  
don't want to muddy up the water by saying that XRD can't use seeAlso  
to imply those semantics. I doubt that it makes sense to define a  
handful of relations just because some pedant afraid of implying  
separate ideas at the same time.

But if you do need more semantic meaning, what exactly do you need?

For example, I don't know what you mean when you ask "is the linked  
XRD every bit as authoritative for related resources as the source  
XRD?" Has someone defined non-boolean types for the authority a  
relation statement can have? I was under the impression that either a  
relation link was considered authoritative, or it wasn't. What middle  
way is there? More importantly, is it valuable to define complex types  
for this sort of authority?

http://josephholsten.com


On Jul 30, 2009, at 1:53 AM, Drummond Reed wrote:

> Generally I'm +1 on using "see-also". However it's fascinating to  
> see how
> subtle the interpretations of the semantics of such a simple phrase  
> can be.
> See
>
> 	http://www.allegrotechindexing.com/news004.htm
>
> ...for an example.
>
> Can we clarify one thing: is the linked XRD considered a full peer  
> with the
> source XRD? In other words, other than the priority of being  
> processed, is
> the linked XRD every bit as authoritative for related resources as the
> source XRD?
>
> If so, regardless of what semantic we use in the rel URI, we should  
> state
> this unambiguously in the text of the spec.
>
> =Drummond
>
>> -----Original Message-----
>> From: Will Norris [mailto:will@willnorris.com]
>> Sent: Tuesday, July 28, 2009 10:12 AM
>> To: Eran Hammer-Lahav
>> Cc: XRI TC
>> Subject: Re: [xri] thoughts on linked XRD rel value
>>
>> yeah, didn't think of that... I like it:
>>
>>   http://docs.oasis-open.org/xri/xrd/rel/see-also
>>
>>
>> On Jul 28, 2009, at 10:07 AM, Eran Hammer-Lahav wrote:
>>
>>> I prefer the relation name to be more explicit, like 'see-also'. The
>>> proposed prefix looks good.
>>>
>>> EHL
>>>
>>>> -----Original Message-----
>>>> From: Will Norris [mailto:will@willnorris.com]
>>>> Sent: Tuesday, July 28, 2009 9:38 AM
>>>> To: XRI TC
>>>> Subject: [xri] thoughts on linked XRD rel value
>>>>
>>>> I believe it was generally agreed upon that we need to come up  
>>>> with a
>>>> new rel value for linked XRDs.  Here's some of my thoughts on  
>>>> that...
>>>>
>>>>
>>>> Do we simply reuse the XRD XML namespace[0]?  I'm thinking no...  
>>>> it's
>>>> just bad practice, and we may eventually need to define other rel
>>>> values in the spec (not likely, but still).
>>>>
>>>> The OASIS guidelines for URI design[1] dictate that URIs (other  
>>>> than
>>>> XML namespaces) should start with "http://docs.oasis-open.org/ 
>>>> xri/".
>>>> I'm figuring we'll need to add an "xrd" path segment under that, as
>>>> well as a "rel" (or "relation") segment.  There's no need to  
>>>> version
>>>> these values as far as I know.  So I'm thinking of something along
>>>> the
>>>> lines of (in no particular order):
>>>>
>>>> http://docs.oasis-open.org/xri/xrd/rel/xrd
>>>> http://docs.oasis-open.org/xri/xrd/rel/linked
>>>> http://docs.oasis-open.org/xri/xrd/rel/linked-xrd
>>>> http://docs.oasis-open.org/xri/xrd/rel/equivalent
>>>>
>>>> Any thoughts on this?  Suggestions for alternate rel values we  
>>>> could
>>>> tack onto the end there?  +/- 1 on any of the above URIs?
>>>>
>>>> Thanks,
>>>> will
>>>>
>>>>
>>>> [0]: http://docs.oasis-open.org/ns/xri/xrd-1.0
>>>> [1]: http://docs.oasis-
>>>> open.org/specGuidelines/namingGuidelines/resourceNaming.html#URI-
>>>> Design
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
> ---------------------------------------------------------------------
> 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
>