W3C home > Mailing lists > Public > public-xg-lld@w3.org > September 2010

RE: [Fwd: Re: on expressing access constraints in a data repository of mixed openness]

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Wed, 22 Sep 2010 10:26:51 -0400
Message-ID: <52E301F960B30049ADEFBCCF1CCAEF5909D6BD00@OAEXCH4SERVER.oa.oclc.org>
To: "Monica Duke" <m.duke@ukoln.ac.uk>, "public-xg-lld" <public-xg-lld@w3.org>

Here are some thoughts on protocol aspects of degrees of openness. 

I wouldn't expect all Linked Data to be open data. If the Linked Data
resources aren't open, though, I hope the URIs secure themselves using
standard HTTP mechanisms. Here are some use cases:

- If you don't want to reveal anything at all to
unauthenticated/unauthorized users, then have the URIs return 401
(Unauthorized), 403 (Forbidden), 404 (Not Found) or 407 (Proxy
Authentication Required) status.
- If you are willing to reveal "free beer" to
unauthenticated/unauthorized users, then create dual HTML and RDF
representations: one each for authenticated/authorized users and one
each for unauthenticated/unauthorized users. For example:

http://example.org/person/1 [300 (See Other) redirect to...]
http://example.org/person/1/ [200 (OK) content-negotiate to...]

http://example.org/person/1/open.html (unauthenticated/unauthorized HTML
http://example.org/person/1/open.rdf (unauthenticated/unauthorized RDF
http://example.org/person/1/closed.html (authenticated/authorized HTML
http://example.org/person/1/closed.rdf (authenticated/authorized RDF

(Using "303 URIs forwarding to One Generic Document"
<http://www.w3.org/TR/cooluris/#r303gendocument> will help preserve SEO
performance by keeping users focused on the generic resource URI. Don't
forget to set the Content-Location header on the generic resource.)

- Crawlers can be deterred by using 503 (Service Unavailable) and an
escalating Retry-After header.
- If you make the RDF available in a resolvable named graph, secure the
graph using HTTP status codes as described above and assert licenses and
restrictions against the graph's URI.
- Include license and restrictions assertions in the RDF for each
individual. (Maybe just on the individuals identified with 303 URIs?)
- Leave the resources open, but put the server behind a firewall (e.g.
make it easier for employees to do their jobs without giving away the

I don't have any suggestion for which license/restriction ontologies
would be best for library resources.


> -----Original Message-----
> From: public-xg-lld-request@w3.org [mailto:public-xg-lld-
> request@w3.org] On Behalf Of Monica Duke
> Sent: Wednesday, September 22, 2010 6:35 AM
> To: public-xg-lld
> Subject: [Fwd: Re: on expressing access constraints in a data
> repository of mixed openness]
> The following query has come up on another mailing list (for
> of data management issues in research) and although the question
> to repositories it made me wonder if this might not also apply to some
> of the library linked data?  Or is there an assumption that all
> (linked)
> data is going to be made available on an open basis?
> I've had a (quick) look at VOID [1] but I could not spot anything that
> fits the request.  The closest is the recommendation for announcing
> license of a dataset.  For automatic analysis it is recommended to use
> "canonical identifiers for well-known licenses" examples given include
> creative commons licenses and GNU.  Perhaps something similar is
> for sharing availability?
> Is such a need likely to arise for library data, and if so are there
> existing methods to communicate the availability or is that a gap that
> the XG could highlight?
> Regards,
> Monica
> [1] http://vocab.deri.ie/void/guide
> -----Original Message-----
> From: Research Data Management discussion list
> [mailto:RESEARCH-DATAMAN@JISCMAIL.AC.UK] On Behalf Of Chris Rusbridge
> Sent: Monday, September 20, 2010 5:17 AM
> Subject: On expressing access constraints in a data repository of
> openness
> [Apologies for cross-posting.]
> I'm looking for some more help. I'm hoping that at the very least the
> discipline of writing down my concern will help me understand it
> better,
> and at best you guys might have a solution.
> Let's imagine an institutional data repository (which I guess could be
> a
> set of different repositories). By definition, the IDR will have data
> that have different degrees of openness. I can distinguish at least
> these conditions:
> a) fully open
> b) closed until some condition is met (then to be open)
> c) closed unless some condition is met
> d) closed indefinitely.
> I'm not really sure an IDR would actually want to accept data with
> condition (d), but there may be good reasons that escape me at the
> moment. But however much one would like all data to be open, there are
> substantial swags of data that must be temporarily or partially
> Independently of conditions (b) to (d), it is possible that some or
> of the metadata might be open, that is to say the data might be
> discoverable even if not open (presumably if you found and wanted to
> use
> the data, then some sort of negotiation would have to take place).
> My question is: how could constraints like these sensibly be
> in either a human-readable or (better) machine-readable way?
> --
> Chris Rusbridge
> Mobile: +44 791 7423828
> Email: c.rusbridge@gmail.com <mailto:c.rusbridge@gmail.com>
Received on Wednesday, 22 September 2010 14:28:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 September 2010 14:28:18 GMT