behind on writing my portion

[Joe Hourcle]

Too many late nights / early mornings due to the paper + ESIP poster caught up with me, and I crashed as soon as I got home last night.

I hope to get you something after my telcon today, but it might not be 'til late afternoon.

Here's my quick draft for the 'serving' re-write, working in a couple of comments (one of them from 3 different people) that I got from the poster at the ESIP meeting.
...



Due to its simplicity, we recommend that HTML landing pages add a <link> element to their HTML landing pages, with the location of alternate landing pages in machine readable formats. For those that are capable of doing so, we recommend also using Web Linking to provide this information from all of the alternative formats.

Should content management systems be developed specifically for maintaining and serving landing pages, we recommend both of these solutions, plus the use of content negotiation.

A more detailed discussion of these techniques, and our justification of using multiple solutions is included in Appendix A. Note that in all of these cases, the alternates are other forms of the landing page. Access to the data itself should be indicated through the appropriate DCAT fields accessURL or downloadURL, as appropriate for the data. Data that is spread across multiple files can be indicated by linking to an ORE resource map.

...

justification notes:


content negotiation :
can specify schemas supported using 'features'
reduces the number of round trips

web linking :
provides linkages from all formats being served
can be retrieved via HEAD requests

html:
remains attached to the document.


if landing pages are dynamically generated, can create on demand, and then cache them to reduce load on the server.


maybe mention when to use downloadURL vs. accessURL vs. ORE.

-Joe