[Peter Wittenburg]

Thanks for these comments. I will look more detailed into the links that were given. I know about the Fairport concept from discussions with Barend Mons, but yet I did not get the idea that the specific problem was tackled, but will look again. Also since we speak about very sensitive mechanisms I see the need to come to cross-disciplinary and global solutions.
In the Data Fabric IG we intend to discuss this issue in more detail in the coming weeks and would be happy on all contributions.
Let me just give two comments here:
– When you look to the PID level I would claim that the problem is mostly solved. We have a PID system layer which is external and which allows us to add for example many URLs to point to various instances. We had one problem which we started discussing with Bob and Larry: currently each PID record has one owner (which makes sense). The question which comes then is how the path to an instance can be changed in the record by a repository that changes its internal paths. Different solutions can be thought of, but we need to respect the requirements for secure operations.
– In Finland people have started to aggregate “authorization records” which allows to manage access permissions etc to all instances of DOs for all copies (instances) in a simple way. Also here we are speaking about a system that has to be highly secure, highly available, etc.
So I would suggest to discuss these issues in the realm of the DFIG group to give it a place and all contributions are welcome.
Best
Peter
From: carole.goble=***@***.***-groups.org [mailto:***@***.***-groups.org] On Behalf Of CaroleGoble
Sent: Thursday, March 12, 2015 9:22 AM
To: puhlir; Working and Interest group Chairs
Cc: apsmith; Data Fabric IG; Mark Wilkinson UPM
Subject: Re: [rda-wg-ig-chairs] Re: [rda-wg-ig-chairs][rda-datafabric-ig] DFIG: White Paper…
I believe that is the approach proposed by the data FAIRPORT profiles.
Datafairport.org
Mark wilkinson at upm has a prototype version. Copied him in.
Carole
Sent from my iPhone by
Professor Carole Goble
The University of Manchester
UK
On 11 Mar 2015, at 17:56, “puhlir”
wrote:
Thank you for this input. We will confer and place it on the discussion agenda for the next call of the IG on March 27th.
Regards,
Paul
On Tue, Mar 10, 2015 at 9:11 PM, apsmith wrote:
So I don’t think this is quite well-thought-out-enough to be called a “use case”, but here’s a little bit of elaboration on the comment I was making this aftenroon.
Peter talked about the split of data repository responsibilities into a “physical layer” and a “logical layer”. The “physical layer” is in principle very simple – a file store with API’s to fetch by ID, etc. The complexity is in the “logical layer”, which holds metadata, provenance, persistent identifiers, relationships, discovery services, analysis tools etc. Dieter in his use case example talked about the difficulty of replicating the logical layer between federated respositories.
So it occurred to me – why not treat the “logical layer” for a given data repository, in its entirety, as one of the datasets + tools that the repository is responsible for, at the physical layer. It would need to have a privileged position, perhaps a special identifier to locate it in the physical layer, so that the system could bootstrap that logical layer to bring up the metadata and services regarding everything else. But in principle if it was treated this way the problem of replication to other repositories in a federated system becomes much simpler, in fact I think the whole overall structure becomes simpler and more flexible. The mechanism for updating the logical layer is the same mechanism you already have for updating every other dataset in the repository – and that includes updating the services the logical layer provides.
Then the “data fabric” solution would also be split into a specification for interoperability of the physical layers of different repositories, and specifications for translating the logical layer format used by one repository into that of another, essentially a data format mapping problem. Or the logical layer might be sufficient to run as a sort of “container” in another repository by itself after bootstrapping – a centralized repository could have several layers with sub-repositories running different “logical layers”.
I can’t say I have any practical experience of doing something like this, it just seemed like the idea fit the discussion this afternoon.
—
Full post: https://rd-alliance.org/group/working-and-interest-group-chairs-data-fab…
Manage my subscriptions: https://rd-alliance.org/mailinglist
Stop emails for this post: https://rd-alliance.org/mailinglist/unsubscribe/47646
—
Full post: https://www.rd-alliance.org/group/working-and-interest-group-chairs/post…
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/47839

Discussion