search

rightsstatements / rights-app

Web application to serve the rightsstatements.org vocabulary
http://rightsstatements.org/vocab/1.0/
European Union Public License 1.1
1 stars 3 forks source link

Dereference vocabulary URI, requesting JSON-LD #14

Closed acka47 closed 8 years ago

acka47 commented 8 years ago

Before we have clarified #12, serve the whole SKOS scheme (as JSON-LD).

acka47 commented 8 years ago

Acceptance criteria:

For the following requests:

server responds:

303 See Other
Location: http://rightsstatements.org/data/1.0/
literarymachine commented 8 years ago

@acka47 are you sure the Location is supposed to include the extension? If dereferencing the vocabulary follow the same pattern as dereferencing an individual statement (see requirements, p. 20), the Location would be http://rightsstatements.org/data/1.0/.

acka47 commented 8 years ago

Oups, you are right. Will edit the acceptance criteria accordingly.

anarchivist commented 8 years ago

If you look at p. 16, there's a SHOULD specified under "Requesting Specific Representations":

The Content-­Location header SHOULD be used to allow a generic machine-­readable representation URI to refer to the URI for a specific machine-­readable representation. URIs for each specific machine­-readable representation SHOULD be linked from the human­-readable representation (e.g. links to download Turtle­-serialized RDF can be obtained using the pattern .../data/x.x/statement.ttl).

acka47 commented 8 years ago

As @anarchivist writea, the extension is included in the Content-Location header when someone e.g makes a GET on http://rightsstatements.org/data/1.0/ requesting turtle. I don't have covered this Content-Location requirement in any acceptance criteria, yet. With the current approach of separating "dereference" and "offer" issues, I actually don't know where to best put it... Will think about it and maybe make a generic issue for this requirement.