Re: [link-relations] NEW RELATION: collection

[mike amundsen <[e-mail]>]

<quote>
> I'm trying to understand whether the intent for Opensearch's <Url> element
> is to use the same relation names as, for instance, the HTTP Link header
> field.
</quote>
Well, I really can't answer that Q. I included OpenSearch since it
_does_ use the same word as a rel value.

<quote>
> In the past we have rejected requests that pointed to private domains.
</quote>
Both values are logged here:
http://microformats.org/wiki/existing-rel-values#non_HTML_rel_values

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me


#RESTFest 2011 - Aug 18-20
http://restfest.org



On Sat, Aug 6, 2011 at 04:25, Julian Reschke <[e-mail]> wrote:
> On 2011-08-06 10:14, mike amundsen wrote:
>>
>> On Sat, Aug 6, 2011 at 04:00, Julian Reschke<[e-mail]>
>>  wrote:
>>>
>>> On 2011-08-06 09:30, mike amundsen wrote:
>>>>
>>>> Relation Name:
>>>> collection
>>>>
>>>> Description:
>>>> The target IRI points to a resource which represents a list of which
>>>> the context  IRI is a member.
>>>>
>>>> References:
>>>> http://www.opensearch.org/Specifications/OpenSearch/1.1#Url_rel_values
>>>> http://amundsen.com/media-types/maze/format/#link-relations
>>>> http://amundsen.com/media-types/collection/format/#link-relations
>>>>
>>>> Notes:
>>>> Logged with the Microformats Existing Rel Values.
>>>> The OpenSearch definition is different than that given above
>>>> ("Represents a request for a set of resources.")
>>>>
>>>> Application Data:
>>>> None
>>>
>>> A few questions:
>>>
>>> Is Opensearch using link relations in the RFC 5988 sense? That is, do
>>> they
>>> share the same space of names?
>>
>> Not sure of this question "share the same space of names"?
>
> I'm trying to understand whether the intent for Opensearch's <Url> element
> is to use the same relation names as, for instance, the HTTP Link header
> field.
>
>>> Also, if this is a new relation name, wouldn't "contained-in" or
>>> something
>>> like that be more accurate? (yep, that's bikeshedding)
>>
>> yeah, might have been better. At this point I'd prefer to not amend the
>> name.
>>
>>>
>>> Finally:
>>>
>>>> http://amundsen.com/media-types/maze/format/#link-relations
>>>> http://amundsen.com/media-types/collection/format/#link-relations
>>>
>>> It would be great if there was a single document defining the link
>>> relation
>>> independently of a specific media type.
>>
>> I have a page that only lists the IANA-related link relations:
>> http://amundsen.com/media-types/linkrelations/registrations/
>>
>> I can split this into a single document for each relation type, if
>> that is the preferred approach.
>
> That might be good; but before that we probably should figure out first
> where this document should live  -- RFC 5988 requests "specification
> required", which in IETF-speak means:
>
>      Specification Required - Values and their meanings must be
>            documented in a permanent and readily available public
>            specification, in sufficient detail so that interoperability
>            between independent implementations is possible.  When used,
>            Specification Required also implies use of a Designated
>            Expert, who will review the public specification and
>            evaluate whether it is sufficiently clear to allow
>            interoperable implementations.  The intention behind
>            "permanent and readily available" is that a document can
>            reasonably be expected to be findable and retrievable long
>            after IANA assignment of the requested value.  Publication
>            of an RFC is an ideal means of achieving this requirement,
>            but Specification Required is intended to also cover the
>            case of a document published outside of the RFC path.  For
>            RFC publication, the normal RFC review process is expected
>            to provide the necessary review for interoperability, though
>            the Designated Expert may be a particularly well-qualified
>            person to perform such a review.
>
> In the past we have rejected requests that pointed to private domains.
>
> Any chance you could put the stuff into an Internet Draft? Template:
> <http://www.ietf.org/mail-archive/web/link-relations/current/msg00152.html>.
>
> Best regards, Julian
>