Skip to content

Design Objective: Follow Best Practices

Jump to bottom
Tim L edited this page May 16, 2014 · 52 revisions
csv2rdf4lod-automation is licensed under the [Apache License, Version 2.0](https://github.com/timrdf/csv2rdf4lod-automation/wiki/License)

Resources

303 Redirects and HTML link

http://vivo.ufl.edu/individual/n1225880055 303s to http://vivo.ufl.edu/display/n1225880055, which includes:

<link rel="alternate" type="application/rdf+xml" href="/individual/n1225880055/n1225880055.rdf" />

LOC example

<link rel="alternate" type="application/rdf+xml" href="http://id.loc.gov/vocabulary/countries.rdf"/>

rapper -q -g -o turtle http://id.loc.gov/vocabulary/countries.html
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://www.w3.org/1999/xhtml> .

<http://id.loc.gov/vocabulary/countries.html>
    <http://www.w3.org/1999/xhtml/vocab#alternate> <http://id.loc.gov/vocabulary/countries.json>, <http://id.loc.gov/vocabulary/countries.nt>, <http://id.loc.gov/vocabulary/countries.rdf>, <http://id.loc.gov/vocabulary/countries/feed/1> ;
    <http://www.w3.org/1999/xhtml/vocab#stylesheet> <http://id.loc.gov/static/css/loc_print_v2.css>, <http://id.loc.gov/static/css/loc_standard_v2.css> .

Semantic Q&A

HTTP 406

That's an ongoing argument in http circles. The spec clearly allows it, and a lot of people think it's the implied recommended behavior. However, the spec has this informative note:

""" Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable. """

I think it's stupid, and clearly has an anti-user feel to it. If you're using Accept headers/conneg, then you have to be checking the content-type of the response anyway, so there shouldn't be any problem with sending them back a response with a type they didn't request if you can't satisfy their conneg preferences directly. But doing the 406 thing ends up fucking people up like you who try to do curl or something and end up with a zero-length content body. It's stupid (especially if there's no content body that tells you what media types are acceptable which IS recommended by the spec).

At the very least our system should include a list of acceptable media types. I'd suggest it should just be picking a canonical one, though, and returning that in case of conneg failure.

-g

URI design

From DWBP:

At the begin of the week I've created a wiki page [1] to write our drafts about URI Design. I've been editing this document with some thoughts and some texts found about the topic. In the document I put a snippet about good and bad pratices for persistent URIs extracted from the ''D7.1.3 - Study on persistent URIs" document (co-authored by Phill) [2]. In addition to that, I was wondering if should we merge this BP URI Doc with the "Data on the Web URI Best Practices (durip)" [3], that is the document written bu Carrasco exposing some good uses and recomendations of URIs to access data on the web. What do you think about it?

[1] https://www.w3.org/2013/dwbp/wiki/URI_Design_and_Management_for_Persistence [2] https://joinup.ec.europa.eu/sites/default/files/c0/7d/10/D7.1.3%20-%20Study%20on%20persistent%20URIs.pdf -That is the original, formal publication, yes. A textually identical version in HTML with fragment IDs everywhere for ease of reference is at http://philarcher.org/diary/2013/uripersistence/ [3] https://www.w3.org/2013/dwbp/wiki/Data_on_the_Web_URI_Best_Practices

Also, please note that the UK work that is referenced by just about everyone is being updated. The latest version is at

https://github.com/UKGovLD/URI-patterns-core/blob/master/URI%20Patterns%20v0.4.md

and includes some important evolutionary steps from the original. There's a closely related doc on URIs for location at https://github.com/UKGovLD/URI-patterns-location/blob/master/URI%20for%20Location%20v0.2.md

The main evolution is encapsulated in the diagram showing the left mid and right hand side of the URI. It's a question of governance as much as tech. I've been working on a related document with the EU institutions that I think will be public soon.

Clone this wiki locally