You can have data which is in a nice “open” format (eg. RDF\/XML rather than HTML) but is not public.<\/p>\n
Mild example; a FOAF profile for a member of staff should not be made public on the web without their permission, but could reasonably be made available to all members of the university.<\/p>\n
Extreme example; exam transcripts should be made available in an electronic & machine readable form if a student (or tutor) wants them, but should be locked down.<\/p>\n
You never want your students & staff giving their username\/password to 3rd party apps willy nilly… although I bet they type it into SSH\/Firefox\/VPN on cybercafes so that ship pretty much sailed, the only difference is a smart phone app can be more targeted.<\/p>\n
Here’s what I’m thinking a first draft of private linked data policy should be:<\/p>\n
There is a web-page on the Intranet, requiring authentication which allows members to generate pass keys for their data, these keys will have a text description for what they are used for and a mandatory expiry date. They can then add “privs” to that key, like “profile data”, “timtable” or “assignments” (with carefully worded warnings about implications). They then cut and paste that key into the app they want to have access to the data.<\/p>\n
The key consists of a username & password for the app to pass to the RDF server to get results. For example cjg-key2\/8347e084309bc20 (where the username is a combo of my username and the key ID)<\/p>\n
28, 14 and 0 days before the key expires the person gets an email telling them it’s expiring\/has expired with a URL to click to add 12 months to the key. Maybe less time if it’s got very sensitive access.<\/p>\n
RDF documents created with the username & password would contain a triple<\/p>\n
\n<> generatedFor <...etc...\/account\/cjg#access-key2> .<\/pre>\n<\/blockquote>\nAnd maybe and rdfs:comment with a deliberate long code in which the org can scan Google to catch if data is leaking.<\/p>\n
Unexpected emergent behaviour<\/h2>\n
I can see one really interesting potential issue with this… If it became standard I can imagine high-pressure parents or even the government of the country an overseas student came from to keep a check on their grades! This is an interesting privacy issue, where a student can’t be *forced* to tell the truth to 3rd parties about their grades until their final graduation (or lack thereof).<\/p>\n
Linked data makes this easier, but the problem exists already. You could just as easily insist the student gave over their normal username\/password for parental or government monitoring.<\/p>\n
Personal data vs Data I can view<\/h2>\n
Toby, one of our student coursework helpdesk guys, made a good point to me; there’s an important distinction between data I can view and data about<\/em> me. A good policy may be to allow people to freely generate keys to any information about themselves (with some advice on the screen), but a key which can access raw data about other people, such as your tutees marks, or the internal university phonebook (with all those DPA-restricted names & numbers in) should require some more formal process, even if it’s data you can view via a portal in HTML.<\/p>\n
That more formal process could be a signature, training or just a bigger EULA style page for you to fail to read.<\/p>\n","protected":false},"excerpt":{"rendered":"
You can have data which is in a nice “open” format (eg. RDF\/XML rather than HTML) but is not public. Mild example; a FOAF profile for a member of staff should not be made public on the web without their permission, but could reasonably be made available to all members of the university. Extreme example; […]<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[198,87,136],"tags":[],"class_list":["post-249","post","type-post","status-publish","format-standard","hentry","category-best-practice","category-intranet","category-rdf"],"_links":{"self":[{"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/posts\/249","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/comments?post=249"}],"version-history":[{"count":3,"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/posts\/249\/revisions"}],"predecessor-version":[{"id":251,"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/posts\/249\/revisions\/251"}],"wp:attachment":[{"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/media?parent=249"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/categories?post=249"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/webteam\/wp-json\/wp\/v2\/tags?post=249"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}