PID Information Types WG

Where we discuss anything related to the RDA (catchall)

Moderators: Leif.Laaksonen, SaraPittonetGaiarin

Re: PID Information Types WG

Postby HermanStehouwer » Sat Dec 01, 2012 3:36 pm

Dear Scott,

At the moment the mailing lists are for group-internal discussion and the forum is for discussion with the entire RDA-community.
I hope this clarifies things somewhat.

As an aside, please don't hesitate to chip in here: http://forum.rd-alliance.org/viewtopic.php?f=2&t=23 to indicate how you think such interaction should be organized :)
The current system is pretty ad-hoc after all.
HermanStehouwer
 
Posts: 28
Joined: Tue Oct 30, 2012 1:19 pm

Re: PID Information Types WG

Postby tobiasweigel » Fri Dec 07, 2012 1:51 pm

All,

I've updated the CWG draft and attached it to the first post. Major changes include:

  • PITs throughout the doc, and a PIT framework as a separate task including processes how to propose and integrate them.
  • Separating concerns and pointing to other WG activities. In particular, all conceptual discussions around definitions of PITs, metadata, data types etc. should be done at the Terminology WG.
  • Profiles and profiles mechanism clarified.

dgbroeder wrote:NB all talk about an API design and prototype implementation also depend on a choice of a PID service provider, not? or do you see the prototype as a complete PID service.


See the doc - the API now has a middleware role and as such is as independent from particular PID providers as possible. I am not exactly sure what you mean by *service* providers - do we need to define these? - I can see that there are services that allow you to create PIDs (e.g. the Handle System or EPIC), but I'd call them PID providers / infrastructures. A service provider would offer something more than that (creation of PITs according to profiles for example). Is that what you meant? Overall, I can imagine that the API specification targets the form of a software library. The prototypic implementation will certainly have to select a single PID infrastructure.
Tobias Weigel, DKRZ
tobiasweigel
 
Posts: 26
Joined: Mon Oct 29, 2012 9:01 am
Location: DKRZ, Hamburg

Re: PID Information Types WG

Postby tobiasweigel » Mon Jan 07, 2013 12:40 pm

All,

there are already a couple of final Case Statements open to discussion in the other forum section, and we'd like to submit ours end of this week. The current version is attached to the first posting in this thread. This is the version we will submit. So if there are any major comments or additions to the case statement, please put them forward now!

Personally I think the statement is as good as it can be made at the current status of the RDA as a whole; I don't think we can get any more precise at this point without restraining the scope or falling into terminological pitfalls. The comments you gave until now were very useful in ensuring this!
Tobias Weigel, DKRZ
tobiasweigel
 
Posts: 26
Joined: Mon Oct 29, 2012 9:01 am
Location: DKRZ, Hamburg

Re: PID Information Types WG

Postby rwmoore » Wed May 08, 2013 7:17 pm

I am responding to the request for PID information type use cases. Within the DataNet Federation Consortium, we use six types of PIDs:
1) globally unique ID that is strictly an identifier with no other meaning. Two objects with the same GUID are assumed to be the same.
2a) handle that associates a location with a PID. In the CNRI handle system, a compound identifier is used. The prefix indicates the specific handle system, and the suffix indicates a file within a handle system. A global registry is used to identify where each handle system is located.
2b) a URL that provides access through a web browser. In the iRODS data grid, a URL can be composed that provides access to public data. An example is
http://iren-web.renci.org:8080/idrop-we ... torial.ppt
3) a Ticket that controls access to the file. In the iRODS data grid, a URL can be created that controls the number of times a file can be accessed, and the time period during which a file can be accessed. An example is
http://iren-web.renci.org:8080/idrop-we ... gPage=true
4) A Ticket can also be created that controls writes to a collection, and limit the amount of data that can be written, the number of files that can be written, and the time period during which writes are allowed.
5) A logical identifier can be created for a file that controls unique identity, access, and arrangement. In the iRODS data grid, logical names can be organized into collections, supporting browsing by collection.
6) Descriptive metadata can be used to identify a file. A query on the descriptive metadata can be resolved to a specific file stored within the data grid.

Reagan Moore
rwmoore
 
Posts: 13
Joined: Thu Nov 08, 2012 3:55 pm

Previous

Return to RDA Discussion Area

Who is online

Users browsing this forum: No registered users and 1 guest

cron