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

Monica,

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
representation)
http://example.org/person/1/open.rdf (unauthenticated/unauthorized RDF
representation)
http://example.org/person/1/closed.html (authenticated/authorized HTML
representation)
http://example.org/person/1/closed.rdf (authenticated/authorized RDF
representation)

(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
farm.)

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

Jeff

> -----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
discussion
> of data management issues in research) and although the question
refers
> 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
the
> 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
needed
> 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
> To: RESEARCH-DATAMAN@JISCMAIL.AC.UK <mailto:RESEARCH-
> DATAMAN@JISCMAIL.AC.UK>
> Subject: On expressing access constraints in a data repository of
mixed
> 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
closed.
> 
> Independently of conditions (b) to (d), it is possible that some or
all
> 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
expressed,
> 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 UTC