Hi Chris,
we had this issue on the PREMIS Implementors Group three years ago. It seemed possible to encode this kind of use restrictions in PREMIS with minor changes to the Data Dictionary. I can send an example to anybody interested.
Regards,
Kai
----
Dr. Kai Naumann
Landesarchiv Baden-Württemberg
– Staatsarchiv Ludwigsburg –
Arsenalplatz 3, D-71638 Ludwigsburg
Telefon: 07141/18-6331 | Fax: 07141/18-6311
E-Mail: [log in to unmask]
-----Original Message-----
From: Research Data Management discussion list [mailto:[log in to unmask]] On Behalf Of Chris Rusbridge
Sent: Monday, September 20, 2010 5:17 AM
To: [log in to unmask]<mailto:[log in to unmask]>
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: [log in to unmask]<mailto:[log in to unmask]>
------------------------------
End of RESEARCH-DATAMAN Digest - 20 Sep 2010 to 21 Sep 2010 (#2010-124)
***********************************************************************
|