- From: Eran Hammer-Lahav <eran@hueniverse.com>
- Date: Thu, 5 Mar 2009 00:03:57 -0700
- To: Jonathan Rees <jar@creativecommons.org>
- CC: "www-talk@w3.org" <www-talk@w3.org>, "www-tag@w3.org WG" <www-tag@w3.org>
This is addressed in section 3: --- To promote interoperability, applications referencing this memo SHOULD clearly define the application-specific criteria used to select between "describedby" links. This MAY be done by: o Supporting a single descriptor format, or defining an order of precedence for multiple descriptor formats. Applications MAY require the presence of the link "type" attribute with the mime- type of the required format. o Using the "describedby" relation type together with another application-specific relation type in the same link. The application-specific relation type can be registered or an extension. o Specifying additional link attributes using link-extensions. --- EHL > -----Original Message----- > From: Jonathan Rees [mailto:jar@creativecommons.org] > Sent: Wednesday, March 04, 2009 10:40 PM > To: Eran Hammer-Lahav > Cc: www-talk@w3.org; www-tag@w3.org WG > Subject: Re: I-D Action:draft-hammer-discovery-02.txt > > What if a single resource needs description resources that are > consumed by different applications, but there is no way to combine the > two DRs into one document, and they cannot be distinguished by media > type? > > Not a problem if the DRs use RDF, but you are not limiting DRs to RDF. > > Registering a new media type for each application is not practical. > > Perhaps you could parameterize DRD by the link relation - that is, > where you now say "describedby", put a variable that takes on a > different value for each application. Then you could use one link > relation for A (POWDER) and another for B (XRD). > > The link-extension feature of Link: (and link-pattern?) might also > help here, although I'm not sure how that would work with <link>. > > Jonathan > > (TAG ISSUE-62) > > > On Feb 12, 2009, at 11:18 PM, Eran Hammer-Lahav wrote: > > > Please discuss on the www-talk@w3.org list. > > > > For those who have read previous revisions (thanks!), please note > > that except for Appendix B, the rest of the spec was significantly > > changed and a fresh read is recommended. > > > > Thanks, > > > > EHL > > > > > > ------ Forwarded Message > > From: <Internet-Drafts@ietf.org> > > Reply-To: <internet-drafts@ietf.org> > > Date: Fri, 13 Feb 2009 00:15:02 -0700 > > To: <i-d-announce@ietf.org> > > Subject: I-D Action:draft-hammer-discovery-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Link-based Resource Descriptor Discovery > > Author(s) : E. Hammer-Lahav > > Filename : draft-hammer-discovery-02.txt > > Pages : 25 > > Date : 2009-02-12 > > > > This memo describes a process for obtaining information about a > > resource identified by a URI. The 'information about a resource', a > > resource descriptor, provides machine-readable information that aims > > to increase interoperability and enhance the interaction with the > > resource. This memo only defines the process for locating and > > obtaining the descriptor, but leaves the descriptor format and its > > interpretation out of scope. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-hammer-discovery-02.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > ------ End of Forwarded Message > > <ATT00001.txt>
Received on Thursday, 5 March 2009 07:04:37 UTC