draft version white paper form DFIG

Thanks Peter,
At this point I strongly suggest that we twist Rob’s arm and ask him to be one of the co-chairs of the group. I know he has done a lot of work on this white paper, has committed to the effort long term, and making him one of the co-chairs will strengthen the RDA/NDS connections. Seems like a no brainer to me.
Best,
Larry

Thanks Larry.
Yes indeed you are raising a point which we should settle soon.
So Gary and I volunteered to push this DF idea ahead and Rob and I volunteered to push the WP issue assuming that both of us have sufficient time.
Let me say that I volunteer to act as co-chair of the DFIG for another year or so from the European side since I would like to further push this group to make progress in RDA. Don't know whether the DFIG is agreeing to this? Also don't know what the plans of others are.
I could also assume that we have this time a (third) co-chair from another region. I know that Yunqiang ZHU from the Geo Institute in Beijing is very active, but I don't know whether he has enough time.
Best
Peter

Larry,
I will also volunteer to be a co-chair for the DFIG and agree with the suggestion from Peter for the third co-chair.
Best regards,
Rob

Peter, Rob,
This is an excellent white paper. You (and he editing team) have done a great job in not only outlining the DFIG space, but also how it fits into RDA. What I especially like is that the white paper does a really good job of capturing what we mean by “data fabric” and how components and pieces fit together to support the larger research and scientific endeavor.
Again, great job.
Thanks
Alan Blatecky

Alan,
This is a very motivating statement - thanks a lot.
peter
From: Alan Blatecky [mailto:***@***.***]
Sent: Friday, December 05, 2014 11:56 AM
To: Peter Wittenburg; Rob Pennington
Cc: ***@***.***-groups.org
Subject: Re: [rda-datafabric-ig] draft version white paper form DFIG
Peter, Rob,
This is an excellent white paper. You (and he editing team) have done a great job in not only outlining the DFIG space, but also how it fits into RDA. What I especially like is that the white paper does a really good job of capturing what we mean by "data fabric" and how components and pieces fit together to support the larger research and scientific endeavor.
Again, great job.
Thanks
Alan Blatecky
On Dec 4, 2014, at 10:57 AM, Peter Wittenburg <***@***.***> wrote:
Dear all,
Here is a first draft version of the white paper which we want to circulate outside of the editing team. All side information you can find in the DFIG group wiki:
https://rd-alliance.org/groups/data-fabric-ig/wiki/data-fabric-ig-docume...
Please comment before Christmas in this thread so that we can work on a first real version 1.X during the Christmas/Newyears days.
Best
Rob & Peter
---------------------------------------------------------------------------------------------------------------
Peter Wittenburg Tel: +49 2821 49180 ***@***.***
RDA Founding Member
EUDAT Scientific Coordinator
Senior Advisor Data Systems
Computer Center Garching
Boltzmannstraße 2
85748 Garching
Germany
http://www.rzg.mpg.de/
http://www.mpi.nl/people/wittenburg-peter
former affiliation:
Max Planck Institute for Psycholinguistics
Wundtlaan 1
6525 XD Nijmegen
The Netherlands
--
Full post: https://www.rd-alliance.org/group/data-fabric-ig/post/draft-version-whit...
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/46723

Dear all,
Some comments and suggestions.
Main points are:
* Still need to make the concept of DF clearer, especially differences with respect to workflow frame works. Suggest to emphasize the ‘pure’ DM application of DF
* I suggest to introduce the idea of the DF as a superset of all DM components and services. Specific combinations of these (“profiles”) may be used to do specific DM work
Please see the attached version for more.
If you have already discussed and clarified these points, i apologise i did not join before, but please still have a look.
Happy Christmas,
Daan
--
Daan Broeder
CTO & Deputy Head
The Language Archive – MPI for Psycholinguistics
+31 24 3521103
***@***.***
P.O. Box 310
6500 AH Nijmegen, The Netherlands
--
From: Peter Wittenburg
<***@***.***>
Date: Thursday, 4 December 2014 16:57
To: "***@***.***-groups.org" <***@***.***-groups.org>
Cc: Peter Wittenburg
<***@***.***>
Subject: [rda-datafabric-ig] draft version white paper form DFIG
Dear all,
Here is a first draft version of the white paper which we want to circulate outside of the editing team. All side information you can find in the DFIG group wiki:
https://rd-alliance.org/groups/data-fabric-ig/wiki/data-fabric-ig-docume...
Please comment before Christmas in this thread so that we can work on a first real version 1.X during the Christmas/Newyears days.
Best
Rob & Peter
---------------------------------------------------------------------------------------------------------------
Peter Wittenburg Tel: +49 2821 49180 ***@***.***
RDA Founding Member
EUDAT Scientific Coordinator
Senior Advisor Data Systems
Computer Center Garching
Boltzmannstraße 2
85748 Garching
Germany
http://www.rzg.mpg.de/
http://www.mpi.nl/people/wittenburg-peter
former affiliation:
Max Planck Institute for Psycholinguistics
Wundtlaan 1
6525 XD Nijmegen
The Netherlands

Thanks Daan.
We received now a few comments on the first draft. In early January we should work on a revised version again. If other people have comments as well, please send them asap.
Bet
Peter
- Show quoted text -From: Daan Broeder
Sent: Tuesday, December 23, 2014 11:10 PM
To: Peter Wittenburg; ***@***.***-groups.org
Subject: Re: [rda-datafabric-ig] draft version white paper form DFIG
Dear all,
Some comments and suggestions.
Main points are:
* Still need to make the concept of DF clearer, especially differences with respect to workflow frame works. Suggest to emphasize the 'pure' DM application of DF
* I suggest to introduce the idea of the DF as a superset of all DM components and services. Specific combinations of these ("profiles") may be used to do specific DM work
Please see the attached version for more.
If you have already discussed and clarified these points, i apologise i did not join before, but please still have a look.
Happy Christmas,
Daan
--
Daan Broeder
CTO & Deputy Head
The Language Archive - MPI for Psycholinguistics
+31 24 3521103
***@***.***
P.O. Box 310
6500 AH Nijmegen, The Netherlands
--
From: Peter Wittenburg
<***@***.***>
Date: Thursday, 4 December 2014 16:57
To: "***@***.***-groups.org" <***@***.***-groups.org>
Cc: Peter Wittenburg
<***@***.***>
Subject: [rda-datafabric-ig] draft version white paper form DFIG
Dear all,
Here is a first draft version of the white paper which we want to circulate outside of the editing team. All side information you can find in the DFIG group wiki:
https://rd-alliance.org/groups/data-fabric-ig/wiki/data-fabric-ig-docume...
Please comment before Christmas in this thread so that we can work on a first real version 1.X during the Christmas/Newyears days.
Best
Rob & Peter
---------------------------------------------------------------------------------------------------------------
Peter Wittenburg Tel: +49 2821 49180 ***@***.***
RDA Founding Member
EUDAT Scientific Coordinator
Senior Advisor Data Systems
Computer Center Garching
Boltzmannstraße 2
85748 Garching
Germany
http://www.rzg.mpg.de/
http://www.mpi.nl/people/wittenburg-peter
former affiliation:
Max Planck Institute for Psycholinguistics
Wundtlaan 1
6525 XD Nijmegen
The Netherlands

Dear all, Peter,
Thanks for all the work already done in this White Paper, which already
gives quite a good impression of what this group is about, and in which
direction it might go.
I have a comment and change suggestion concerning the white paper, which
seems only to be a small correction in diagram 5:
the arrow between the metadata object and the PID record should be
bidirectional.
Because I think, that this is important but on the other hand that it
might raise some discussions how data, metadata and PIDs are (or have to
be) organized, I will try to justify this in the following. If you
immediatly agree, just ignore the rest (except the BTW).
As mentioned in the White Paper this diagram is a core part of the
framework, because it tries to describe schematically the processes and
its input and output elements on an atomic level. Since both, input and
output elements are triples of the same kind, these triples are somehow
elementary of the framework and the question arises, how these triples
are referred to inside the framework.
With reference here I mean the technical reference, but also it makes
sense to have a good name for these triples. But this is another discussion.
The technical reference to the basic elements in a framework always
plays an important role, as inside the framework workflows these basic
elements are used and transferred via its reference, the pointers, as
long as possible. This is also why pointers play such an important role
in programming.
In the current version of the diagram the technical reference to all
components of the triple is only possible via the metadata object,
because only this points to the PID record and from there to the digital
object. There is no direct way to get the metadata, if one only has the
PID record as reference to the digital object. This always needs a
search inside all the metadata records.
The consequence would be, that the framework would be essentially driven
by metadata objects organized in some metadata registry. From my point
of view this only would work efficiently, safe and interoperable, if
also the metadata objects have identifiers like PIDs that can be used as
lightweight pointers in the processes. In this case we have to extend
the triples to quadrupels, containing also the PID referring to the
metadata object, and we have a three step resolution to come from the
pointer of the quardupel to the digital object. But at the end this
could also be a possible extension of the diagram.
The other solution would be to use the PID record, that points to the
digital object, also as reference to the metadata object. Several PID
systems are able to setup such an additional reference. In this case the
whole triple can be referred to by this PID record very efficiently. The
metadate as well as the digital object are directy resolved in this
construction. From my point of view this solution would be more elegant
(in the sense of Occam's razor), because it uses less resources and
gives more direct access to all the necessary information.
At least for the further discussions I would emphasise the possibility
of such a solution by allowing the reference between PID record and
metadata object in both directions. Whether this additional arrow
direction is implemented in the concrete case is another question, that
is addressed by the formulation, that the diagram illustrates possible
processing at the atomic level.
BTW. A happy New Year to everybody.