RDTF Metadata Guidelines: an update

832 views

Published on

Presentation to the Resource Discovery Task Force Management Group, summarising thoughts on next steps with the RDTF Metadata Guidelines.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
832
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

RDTF Metadata Guidelines: an update

  1. 1. RDTF Metadata Guidelinesan update<br />Andy Powell (and Pete Johnston)<br />RDTF Management Framework<br />Project Board<br />29 March2011<br />
  2. 2. Functional requirement<br />help libraries, museums and archives expose existing metadata (and new metadata created using existing practice) in ways that<br />support the development of aggregator services<br />integrate well with the web (and the emerging web of data)<br />note:RDTF is not about re-engineering cataloguing practice in the LAM sectors<br />
  3. 3. Guiding principles<br />support the RDTF Vision<br />informed by Paul Miller’s desk study review<br />flow from the JISC IE Technical Review meeting<br />in line with Linked Data principles<br />based on the W3C Linked Open Data Star Scheme<br />in line with Designing URI Sets for the UK Public Sector<br />take into account the Europeana Data Model and ESE<br />be informed by mainstream web practice and search engine behaviour and be broadly in line with the notion of “making better websites” across the library, museum and archives sectors<br />
  4. 4. Draft proposal<br />used the W3C Linked Open Data star scheme as framework (at 3, 4 and 5 star levels)<br />three approaches<br />community formats<br />RDF data<br />Linked Data<br />196 comments – on pretty much all aspects of the draft<br />
  5. 5. Guiding principles<br />support the RDTF Vision<br />informed by Paul Miller’s desk study review<br />flow from the JISC IE Technical Review meeting<br />in line with Linked Data principles<br />based on the W3C Linked Open Data Star Scheme<br />in line with Designing URI Sets for the UK Public Sector<br />take into account the Europeana Data Model and ESE<br />be informed by mainstream web practice and search engine behaviour and be broadly in line with the notion of “making better websites” across the library, museum and archives sectors<br />We probably failed in this!!<br />
  6. 6. Re-conceptualising the guidelines<br />RDF<br />Not-RDF<br />Individual ItemDescriptions<br />Linked Data<br />“page per thing”<br />Collectionsof Descriptions<br />“RDF Data”<br />“bulk download”<br />
  7. 7. The draft guidelines<br />RDF<br />Not-RDF<br />Individual ItemDescriptions<br />Linked Data<br />“page per thing”<br />Collectionsof Descriptions<br />“RDF Data”<br />“bulk download”<br />
  8. 8. The Web!<br />RDF<br />Not-RDF<br />Individual ItemDescriptions<br />Linked Data<br />“page per thing”<br />Collectionsof Descriptions<br />“RDF Data”<br />“bulk download”<br />
  9. 9. Possible adoption path<br />RDF<br />Not-RDF<br />Individual ItemDescriptions<br />Linked Data<br />“page per thing”<br />Collectionsof Descriptions<br />“RDF Data”<br />“bulk download”<br />
  10. 10. Bulk download<br />“give us what you’ve got”<br />serve existing community bulk-formats (e.g. files containing collections of MARC, MODS, BibTeX, DC/XML, SPECTRUM or EAD records) or CSV over RESTfulHTTP<br />use sitemaps and robots.txt and/or RSS/Atom to advertise availability and GZip for compression<br />for CSV, providea column called ‘label’ or ‘title’ so we’ve got something to display<br />give us separate records (for CSV, read ‘rows’) about separate resources (where you can)<br />simples!<br />
  11. 11. Page per thing<br />“build better websites”<br />serve an HTML page (i.e. a description) for every “thing” of interest over RESTful HTTP<br />optionally serve alternative format(s) for each description (e.g. a MODS or DC/XML record) at separate URIs and link from the HTML descriptions using “<link rel=“alternative” … /><br />use “cool” ‘http’ URIs for all descriptions<br />use sitemaps and robots.txt and/or RSS/Atom to advertise availability<br />optionally offer OAI-PMH server to allow harvesting of all descriptions/formats<br />
  12. 12. RDF data<br />“RDF bulk download”<br />serve big buckets of RDF (as RDF/XML, N-Tuples or N-Quads) over RESTful HTTP<br />re-use existing conceptual models and vocabularies where you can<br />assign URIs to every “thing” of interest<br />use Semantic Sitemaps and the Vocabulary of Interlinked Datasets (VoID) to advertise availability of the buckets<br />
  13. 13. Linked Data<br />“W3C 5 star approach”<br />serve HTML and RDF/RDFa for every “thing” of interest over RESTful HTTP<br />assign‘http’ URIs to every “thing” (and every description of a thing)<br />follow “cool URIs for the semantic web” recommended practice<br />become part of the web of data - link to other people’s stuff using their URIs <br />
  14. 14. Recommendations<br />use the four-quadrant model to frame the guidelines (we think all four quadrants are useful, and that there should probably be some guidance on each area)<br />develop specific guidance for serving an HTML page description per 'thing' of interest (possibly with associated, and linked, alternative formats such as DC/XML)<br />develop (or find) specific guidance about how to sensibly assign persistent 'http' URIs to everything of interest (including both things and descriptions of things)<br />
  15. 15. Also…<br />that the definition of 'open' needs more work (particularly in the context of whether commercial use is allowed) but that this needs to be sensitive to not stirring up IPR-worries in those domains where they are less of a concern currently<br />that mechanisms for making statements of provenance, licensing and versioning be developed where RDF triples are being made available (possibly in collaboration with Europeana work)<br />that a fuller list of relevant models that might be adopted, the relationships between them, and any vocabularies commonly associated with them be maintained separately from the guidelines themselves<br />
  16. 16. Fin<br />

×