Re: [vre_ig] Virtual Research Environments and Reference Architecture(s)...

Mmm I hope this is not too late but excellent discussion and I tend to
agree with Jose :) That we should define interoperability, which will help
with items to consider when developing/ and operating a VRE and defining
reference architectures.
From my perspective (running a VL BCCVL and developing a Science Cloud),
interoperability needs to be defined at the end points of each system. What
happens within the system is not of such a concern as long as we can *know*
and can *access* the VRE's outputs, data or evoke a process (which we
ultimately want in a M2M - API environment).
Also we should look at interoperability in terms of the user and workflows.
In some cases it is easier to pull data/ evoke processes into a VRE (such
as a simple query/ look up) other times it is better to push outputs to
another VRE (this is the case when manipulating or visualising the data is
specialised).
If taking that perspective, items I'm concerned with are:
- Discovering what processes and data you can, access, evoke or transfer;
- Authentication/ Authorisation - how to push or pull so their is
minimal user friction;
- Transfer of data - how is data transferred and stored. How do I know
its complete;
- System reliability - if I am going to interoperate with an external
system - how do I know it is reliable and trustworthy.
[image: Inline images 1]
There is also interoperability potential when contemplating shared file
systems the provide reference data and access to outputs for many VRE's.
Cheers,
Hamish

Hamish –
Many thanks for the useful comments and perspective.
I agree totally that VREs could be regarded as black boxes and expose the assets they are willing to expose through external interfaces.
These interfaces are – most conveniently – standard services such as the query you mention but of course many others, and commonly multistep (e.g. query catalog then query dataset(s)).
It would be helpful if at least a common core of standard services were available at all VRE external interfaces.
The problems are of course not solved; they are just hidden under the service. Those problems are resolution of heterogeneous syntax and semantics.
Best
Keith
--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
Past President ERCIM www.ercim.eu (***@***.***)
Past President euroCRIS www.eurocris.org
Past Vice President VLDB www.vldb.org
Fellow (CITP, CEng) BCS www.bcs.org
Co-chair RDA MIG https://rd-alliance.org/internal-groups/metadata-ig.html
Co-chair RDA MSDWG https://rd-alliance.org/working-groups/metadata-standards-directory-work...
Co-chair RDA DICIG https://rd-alliance.org/internal-groups/data-context-ig.html
----------------------------------------------------------------------------------------------------------------------------------
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
----------------------------------------------------------------------------------------------------------------------------------
From: Hamish Holewa [mailto:***@***.***]
Sent: 06 April 2017 00:30
To: kheerand <***@***.***>
Cc: ***@***.***; Virtual Research Environment IG (VRE-IG) <***@***.***-groups.org>; Keith Jeffery <***@***.***>
Subject: Re: [vre_ig] Re: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
Mmm I hope this is not too late but excellent discussion and I tend to agree with Jose :) That we should define interoperability, which will help with items to consider when developing/ and operating a VRE and defining reference architectures.
From my perspective (running a VL BCCVL and developing a Science Cloud), interoperability needs to be defined at the end points of each system. What happens within the system is not of such a concern as long as we can know and can access the VRE's outputs, data or evoke a process (which we ultimately want in a M2M - API environment).
Also we should look at interoperability in terms of the user and workflows. In some cases it is easier to pull data/ evoke processes into a VRE (such as a simple query/ look up) other times it is better to push outputs to another VRE (this is the case when manipulating or visualising the data is specialised).
If taking that perspective, items I'm concerned with are:
* Discovering what processes and data you can, access, evoke or transfer;
* Authentication/ Authorisation - how to push or pull so their is minimal user friction;
* Transfer of data - how is data transferred and stored. How do I know its complete;
* System reliability - if I am going to interoperate with an external system - how do I know it is reliable and trustworthy.
[Inline images 1]
There is also interoperability potential when contemplating shared file systems the provide reference data and access to outputs for many VRE's.
Cheers,
Hamish
On 6 April 2017 at 00:10, kheerand <***@***.***> wrote:
HI Jose,
I agree with both the 4 views and the approach you are suggesting and feel that, if we do a good job, it will lead to a good outcome that is likely to be adopted rapidly, which ultimately is what will provide the interoperability we are seeking.
Cheers
Kheeran
On Wed, Apr 5, 2017 at 11:21 PM, Jose Borbinha <***@***.***> wrote:
Hi,
An important clarification, as I realize from Keith’ words below that I might has passed the wrong message: I’m not proposing we should follow the 4 steps below in a waterfall process! “Au contraire”, it only can work if we can do it agile/spiral. To be more correct, these “4 levels” should be seen more correctly as “views”, which must all be coherently developed “in parallel”.
In other words, we can name them:
The VRA vocabulary (one “thing”)
The VRA meta domain model (ideally only one)
The VRA domain models (multiple…)
The VRA instances (multiple…)
If, for example, we understand this as a classic “requirements engineering process” (what I support) we should indeed start by “raising the most evident facts”, I mean, precisely look at the present instances and give voice and listen their respective stakeholders, draft from that the common vocabulary and the meta domain, creating that way a “minimal common ground”, and then iterate that until we are satisfied (which should occur because everyone can realize our common knowledge already had been captured and is represented, and not because we dye exhaust ;-)
From: Jose Borbinha [mailto:***@***.***]
Sent: Wednesday, April 5, 2017 2:07 PM
To: 'Keith Jeffery' <***@***.***>; ***@***.***; 'kheerand' <***@***.***>; 'Virtual Research Environment IG (VRE-IG)' <***@***.***-groups.org>
Subject: RE: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
under “my” framework below, I understand “interoperability” as one of the core concepts we, precisely, should define first… and then let us realize the architectural implications of that definition…
It might sound silly from my side, but I’m not sure if we all have the same concept in mind when we use that word ;-)
jlb
From: Keith Jeffery [mailto:***@***.***]
Sent: Wednesday, April 5, 2017 1:49 PM
To: ***@***.***; 'kheerand' <***@***.***>; 'Virtual Research Environment IG (VRE-IG)' <***@***.***-groups.org>
Subject: RE: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
José –
Many thanks for the comments. Generally I agree. We start to part company over ‘profiles’. It is here that the specialization to profiles conflicts with maximum interoperability. However, for some applications the interoperability may only be needed over some few core attributes and local processing can deal with the specialisations of the profile.
Best
Keith
--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
Past President ERCIM www.ercim.eu (***@***.***)
Past President euroCRIS www.eurocris.org
Past Vice President VLDB www.vldb.org
Fellow (CITP, CEng) BCS www.bcs.org
Co-chair RDA MIG https://rd-alliance.org/internal-groups/metadata-ig.html
Co-chair RDA MSDWG https://rd-alliance.org/working-groups/metadata-standards-directory-work...
Co-chair RDA DICIG https://rd-alliance.org/internal-groups/data-context-ig.html
----------------------------------------------------------------------------------------------------------------------------------
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
----------------------------------------------------------------------------------------------------------------------------------
From: Jose Borbinha [mailto:***@***.***]
Sent: 05 April 2017 10:21
To: Keith Jeffery <***@***.***>; 'kheerand' <***@***.***>; 'Virtual Research Environment IG (VRE-IG)' <***@***.***-groups.org>
Cc: 'José Borbinha' <***@***.***>
Subject: RE: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
Hi!
My 5cents for this discussion…
I believe we are all moving to the same point, but some are moving botton-up and other top-down… But I believe in the end we are going to meet “in the same spot” ;-)
In “short” (short in argument, not in words, as I ended writing a lot of them below…), IMHO this problem belongs to a class that in information systems and conceptual modeling we are used to “see” at 4 levels:
- Core concepts (e.g.”what is the definition of VRE that we all are comfortable with…”, …as for other core concepts…). In conceptual modeling we call this “the entities of the domain model”, and can be represented in its simplest form as a list of terms and definitions, but also can be a thesaurus for example (simply, the same terms, but already with some relations among them for “equivalent”, “broader term”, …)
- Core reference architecture (in simple terms, this can be “simply” the way the previous core concepts “play together”… In conceptual modeling this is the “domain model”, which represents the core concepts and the associations among them (this is important, as from this step it also might result some associations are turned to be new concepts…). This can be represented in many/multiple techniques, as free text, as ontology(ies), or also using specialized visual languages (ArchiMate, UML, BPMN, …). It should be agnostic of any specific application/concretization/deployment scenario… Anyway, at this level it is a good principle to give special attention to two major views, one for the “structure” (the “things, as blocks” that must make the VRE) and the “behavior” (what is a VRE as a “thing that communicates” – usual terms to designate this can be “services”, or “use cases”, etc…). Other key principle is to be technology neutral (unless some very strong constrain exists…).
- Profile architecture(es): here is when we face reality and recognize the precious core model needs to be specialized for some domain applications. That can motivate the (controlled) extension of the core vocabulary, and the specialization of the core architecture (by specialization I intend to mean “for this purpose, the core concept X means now Y”, where Y must still be “of the class” of X, but is now more elaborated/detailed for the concerned purpose). When this can be made in a “closed” way, I mean, a set of specialized new requirements can be realized and producing a new product that is coherent with the initial core, we can assume we both validated the core and produced a new “Profile” (“profile” is a common term, but other terms can be considered to designate it, such as “viewpoint”, “facet ?”, “domain ontology ?”, … can depend of the culture of the domain and of the techniques in place…). This profile concept can be applied to multiple domains, and even at multiple levels (for examples, we can agree they exist the domains A, B and C, but A also as A.1, A.2, etc…). If this can be done with success, we can assume the core architecture is relevant. Otherwise, it all must be revised accordingly… At this level we also must keep as possible the principle of technology neutrality, but “profiles” that already take in consideration technological constraints might be to consider…
- Finally, we have the local deployments/instantiations… Once again, those can vary a lot, but still be conformant with the reference architecture. If that cannot be done, the overall thing should be revised…
Best!
José Borbinha
- Show quoted text -From: keith.jeffery=***@***.***-groups.org [mailto:***@***.***-groups.org] On Behalf Of ***@***.***
Sent: Wednesday, April 5, 2017 8:56 AM
To: kheerand <***@***.***>; Virtual Research Environment IG (VRE-IG) <***@***.***-groups.org>
Subject: Re: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
Kheerand –
Many thanks for your comments.
I certainly agree that there is room for specialised research environments. However, for interoperability (recall RDA is about data access and interoperability) life is very complex if there are many architectures (or at least many heterogeneous specifications and implementations). Hence the idea of one reference architecture for this purpose – more specifically one specification of a conceptual (not necessarily realised physically) rich canonical metadata scheme as the conversion target from each local catalog. This has been known and discussed in the literature for >30 years. Implementation is of course difficult, hence currently progress is made commonly in domain-specific implementations with limited interoperability.
I also agree that if we can find agreed definitions of terms that would assist greatly in reducing confusion. I agree that implementations based on the (finally agreed) reference architecture are necessary to prove the architecture.
Thanks again for the comments
Best
Keith
--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
Past President ERCIM www.ercim.eu (***@***.***)
Past President euroCRIS www.eurocris.org
Past Vice President VLDB www.vldb.org
Fellow (CITP, CEng) BCS www.bcs.org
Co-chair RDA MIG https://rd-alliance.org/internal-groups/metadata-ig.html
Co-chair RDA MSDWG https://rd-alliance.org/working-groups/metadata-standards-directory-work...
Co-chair RDA DICIG https://rd-alliance.org/internal-groups/data-context-ig.html
----------------------------------------------------------------------------------------------------------------------------------
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
----------------------------------------------------------------------------------------------------------------------------------
From: kheerand=***@***.***-groups.org [mailto:***@***.***-groups.org] On Behalf Of kheerand
Sent: 05 April 2017 08:40
To: Virtual Research Environment IG (VRE-IG) <***@***.***-groups.org>
Subject: Re: [vre_ig] Virtual Research Environments and Reference Architecture(s) for them
Hi all,
I am unfortunately not going to be in Barcelona but I hope my contributions here helps in the discussions in Barcelona.
Expanding and responding to Leo's comments, I too am of the view that in the research space a single reference architecture is unlikely to have much utility. The diversity across research domains are so vast that we either end up having a reference architecture that is too abstract and vague to be of practical use, or we have a reference architecture that ends up very useful for some domains but not others. My suggestion is we should look at a set of reference architectures that are quite diverse yet well suited to non-overlapping research domains. I feel this way we will be able to have a set of reference architectures that collectively have a broad reach and has good utility.
Another thing that I would like to comment on is that I feel we haven't got a clear understanding of what a VRE is for the purpose of creating Reference Architectures. From my reading, we seem to define VRE as defined by VRE4EIC, and then include Virtual Laboratories and Science Gateways as also being VREs. VRE (as defined by VRE4EIC), VL & Science Gateways, while closely related are also subtly different. I think we would be well served if we develop a clear definition of what we mean by a VRE and then compare and contrast VRE4EIC, VL and Science Gateways against this definition.
I would also like to see this IG not only develop Reference architectures but also develop a set of implementation patterns that are derived from current (successful) implementations of VREs, VLs & SGs that map back to the reference architectures. I believe this would then provide practical guidance to those who are developing VREs for research.
One final comment I'd like to make is that when we consider interoperability we should do so at two levels. Interoperability between e-RIs across domains, and interoperability between e-RIs within a domain. It is important for us to continue to recognise that specilised coupling of e-RI, e-I within a particular research domain is crucial to advancing that field of research and pushing the boundaries of knowledge. I would assert that this should be the primary concern and hence why current investment and effort has been focused around specific domains. However there is also many advantages of having interoperability across domains, and in many respects far more challenging to achieve in practice. So a reference architecture can be of great help.
Kind regards
Kheeran Dharmawardena
--
Full post: https://www.rd-alliance.org/group/virtual-research-environment-ig-vre-ig...
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/55766
--
Full post: https://www.rd-alliance.org/group/virtual-research-environment-ig-vre-ig...
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/55913
--
Hamish Holewa BSc (Comp Sci), BEd, GradDip HEcon
Biodiversity Climate Change Virtual Laboratory Program Manager See our 2016 Year Snapshot www.bccvl.org.au
EcoCloud and RDS Terrestrial Systems Program Manager
Quadrant Project Director and Manager www.quadrant.edu.au
QCIF Project Manager www.qcif.edu.au
***@***.***
+61 (0) 4 000 27 653
Hamish –
Many thanks for the useful comments and perspective.
I agree totally that VREs could be regarded as black boxes and expose the assets they are willing to expose through external interfaces.
These interfaces are – most conveniently – standard services such as the query you mention but of course many others, and commonly multistep (e.g. query catalog then query dataset(s)).
It would be helpful if at least a common core of standard services were available at all VRE external interfaces.
The problems are of course not solved; they are just hidden under the service. Those problems are resolution of heterogeneous syntax and semantics.
Best
Keith
--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
Past President ERCIM www.ercim.eu (***@***.***)
Past President euroCRIS www.eurocris.org
Past Vice President VLDB www.vldb.org
Fellow (CITP, CEng) BCS www.bcs.org
Co-chair RDA MIG https://rd-alliance.org/internal-groups/metadata-ig.html
Co-chair RDA MSDWG https://rd-alliance.org/working-groups/metadata-standards-directory-work...
Co-chair RDA DICIG https://rd-alliance.org/internal-groups/data-context-ig.html
----------------------------------------------------------------------------------------------------------------------------------
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
----------------------------------------------------------------------------------------------------------------------------------
From: Hamish Holewa [mailto:***@***.***]
Sent: 06 April 2017 00:30
To: kheerand <***@***.***>
Cc: ***@***.***; Virtual Research Environment IG (VRE-IG) <***@***.***-groups.org>; Keith Jeffery <***@***.***>
Subject: Re: [vre_ig] Re: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
Mmm I hope this is not too late but excellent discussion and I tend to agree with Jose :) That we should define interoperability, which will help with items to consider when developing/ and operating a VRE and defining reference architectures.
From my perspective (running a VL BCCVL and developing a Science Cloud), interoperability needs to be defined at the end points of each system. What happens within the system is not of such a concern as long as we can know and can access the VRE's outputs, data or evoke a process (which we ultimately want in a M2M - API environment).
Also we should look at interoperability in terms of the user and workflows. In some cases it is easier to pull data/ evoke processes into a VRE (such as a simple query/ look up) other times it is better to push outputs to another VRE (this is the case when manipulating or visualising the data is specialised).
If taking that perspective, items I'm concerned with are:
* Discovering what processes and data you can, access, evoke or transfer;
* Authentication/ Authorisation - how to push or pull so their is minimal user friction;
* Transfer of data - how is data transferred and stored. How do I know its complete;
* System reliability - if I am going to interoperate with an external system - how do I know it is reliable and trustworthy.
[Inline images 1]
There is also interoperability potential when contemplating shared file systems the provide reference data and access to outputs for many VRE's.
Cheers,
Hamish
On 6 April 2017 at 00:10, kheerand <***@***.***> wrote:
HI Jose,
I agree with both the 4 views and the approach you are suggesting and feel that, if we do a good job, it will lead to a good outcome that is likely to be adopted rapidly, which ultimately is what will provide the interoperability we are seeking.
Cheers
Kheeran
On Wed, Apr 5, 2017 at 11:21 PM, Jose Borbinha <***@***.***> wrote:
Hi,
An important clarification, as I realize from Keith’ words below that I might has passed the wrong message: I’m not proposing we should follow the 4 steps below in a waterfall process! “Au contraire”, it only can work if we can do it agile/spiral. To be more correct, these “4 levels” should be seen more correctly as “views”, which must all be coherently developed “in parallel”.
In other words, we can name them:
The VRA vocabulary (one “thing”)
The VRA meta domain model (ideally only one)
The VRA domain models (multiple…)
The VRA instances (multiple…)
If, for example, we understand this as a classic “requirements engineering process” (what I support) we should indeed start by “raising the most evident facts”, I mean, precisely look at the present instances and give voice and listen their respective stakeholders, draft from that the common vocabulary and the meta domain, creating that way a “minimal common ground”, and then iterate that until we are satisfied (which should occur because everyone can realize our common knowledge already had been captured and is represented, and not because we dye exhaust ;-)
From: Jose Borbinha [mailto:***@***.***]
Sent: Wednesday, April 5, 2017 2:07 PM
To: 'Keith Jeffery' <***@***.***>; ***@***.***; 'kheerand' <***@***.***>; 'Virtual Research Environment IG (VRE-IG)' <***@***.***-groups.org>
Subject: RE: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
under “my” framework below, I understand “interoperability” as one of the core concepts we, precisely, should define first… and then let us realize the architectural implications of that definition…
It might sound silly from my side, but I’m not sure if we all have the same concept in mind when we use that word ;-)
jlb
From: Keith Jeffery [mailto:***@***.***]
Sent: Wednesday, April 5, 2017 1:49 PM
To: ***@***.***; 'kheerand' <***@***.***>; 'Virtual Research Environment IG (VRE-IG)' <***@***.***-groups.org>
Subject: RE: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
José –
Many thanks for the comments. Generally I agree. We start to part company over ‘profiles’. It is here that the specialization to profiles conflicts with maximum interoperability. However, for some applications the interoperability may only be needed over some few core attributes and local processing can deal with the specialisations of the profile.
Best
Keith
--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
Past President ERCIM www.ercim.eu (***@***.***)
Past President euroCRIS www.eurocris.org
Past Vice President VLDB www.vldb.org
Fellow (CITP, CEng) BCS www.bcs.org
Co-chair RDA MIG https://rd-alliance.org/internal-groups/metadata-ig.html
Co-chair RDA MSDWG https://rd-alliance.org/working-groups/metadata-standards-directory-work...
Co-chair RDA DICIG https://rd-alliance.org/internal-groups/data-context-ig.html
----------------------------------------------------------------------------------------------------------------------------------
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
----------------------------------------------------------------------------------------------------------------------------------
From: Jose Borbinha [mailto:***@***.***]
Sent: 05 April 2017 10:21
To: Keith Jeffery <***@***.***>; 'kheerand' <***@***.***>; 'Virtual Research Environment IG (VRE-IG)' <***@***.***-groups.org>
Cc: 'José Borbinha' <***@***.***>
Subject: RE: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
Hi!
My 5cents for this discussion…
I believe we are all moving to the same point, but some are moving botton-up and other top-down… But I believe in the end we are going to meet “in the same spot” ;-)
In “short” (short in argument, not in words, as I ended writing a lot of them below…), IMHO this problem belongs to a class that in information systems and conceptual modeling we are used to “see” at 4 levels:
- Core concepts (e.g.”what is the definition of VRE that we all are comfortable with…”, …as for other core concepts…). In conceptual modeling we call this “the entities of the domain model”, and can be represented in its simplest form as a list of terms and definitions, but also can be a thesaurus for example (simply, the same terms, but already with some relations among them for “equivalent”, “broader term”, …)
- Core reference architecture (in simple terms, this can be “simply” the way the previous core concepts “play together”… In conceptual modeling this is the “domain model”, which represents the core concepts and the associations among them (this is important, as from this step it also might result some associations are turned to be new concepts…). This can be represented in many/multiple techniques, as free text, as ontology(ies), or also using specialized visual languages (ArchiMate, UML, BPMN, …). It should be agnostic of any specific application/concretization/deployment scenario… Anyway, at this level it is a good principle to give special attention to two major views, one for the “structure” (the “things, as blocks” that must make the VRE) and the “behavior” (what is a VRE as a “thing that communicates” – usual terms to designate this can be “services”, or “use cases”, etc…). Other key principle is to be technology neutral (unless some very strong constrain exists…).
- Profile architecture(es): here is when we face reality and recognize the precious core model needs to be specialized for some domain applications. That can motivate the (controlled) extension of the core vocabulary, and the specialization of the core architecture (by specialization I intend to mean “for this purpose, the core concept X means now Y”, where Y must still be “of the class” of X, but is now more elaborated/detailed for the concerned purpose). When this can be made in a “closed” way, I mean, a set of specialized new requirements can be realized and producing a new product that is coherent with the initial core, we can assume we both validated the core and produced a new “Profile” (“profile” is a common term, but other terms can be considered to designate it, such as “viewpoint”, “facet ?”, “domain ontology ?”, … can depend of the culture of the domain and of the techniques in place…). This profile concept can be applied to multiple domains, and even at multiple levels (for examples, we can agree they exist the domains A, B and C, but A also as A.1, A.2, etc…). If this can be done with success, we can assume the core architecture is relevant. Otherwise, it all must be revised accordingly… At this level we also must keep as possible the principle of technology neutrality, but “profiles” that already take in consideration technological constraints might be to consider…
- Finally, we have the local deployments/instantiations… Once again, those can vary a lot, but still be conformant with the reference architecture. If that cannot be done, the overall thing should be revised…
Best!
José Borbinha
From: keith.jeffery=***@***.***-groups.org [mailto:***@***.***-groups.org] On Behalf Of ***@***.***
Sent: Wednesday, April 5, 2017 8:56 AM
To: kheerand <***@***.***>; Virtual Research Environment IG (VRE-IG) <***@***.***-groups.org>
Subject: Re: [vre_ig] Virtual Research Environments and Reference Architecture(s)...
Kheerand –
Many thanks for your comments.
I certainly agree that there is room for specialised research environments. However, for interoperability (recall RDA is about data access and interoperability) life is very complex if there are many architectures (or at least many heterogeneous specifications and implementations). Hence the idea of one reference architecture for this purpose – more specifically one specification of a conceptual (not necessarily realised physically) rich canonical metadata scheme as the conversion target from each local catalog. This has been known and discussed in the literature for >30 years. Implementation is of course difficult, hence currently progress is made commonly in domain-specific implementations with limited interoperability.
I also agree that if we can find agreed definitions of terms that would assist greatly in reducing confusion. I agree that implementations based on the (finally agreed) reference architecture are necessary to prove the architecture.
Thanks again for the comments
Best
Keith
--------------------------------------------------------------------------------
Keith G Jeffery Consultants
Prof Keith G Jeffery
E: ***@***.***
T: +44 7768 446088
S: keithgjeffery
Past President ERCIM www.ercim.eu (***@***.***)
Past President euroCRIS www.eurocris.org
Past Vice President VLDB www.vldb.org
Fellow (CITP, CEng) BCS www.bcs.org
Co-chair RDA MIG https://rd-alliance.org/internal-groups/metadata-ig.html
Co-chair RDA MSDWG https://rd-alliance.org/working-groups/metadata-standards-directory-work...
Co-chair RDA DICIG https://rd-alliance.org/internal-groups/data-context-ig.html
----------------------------------------------------------------------------------------------------------------------------------
The contents of this email are sent in confidence for the use of the
intended recipient only. If you are not one of the intended
recipients do not take action on it or show it to anyone else, but
return this email to the sender and delete your copy of it.
----------------------------------------------------------------------------------------------------------------------------------
- Show quoted text -From: kheerand=***@***.***-groups.org [mailto:***@***.***-groups.org] On Behalf Of kheerand
Sent: 05 April 2017 08:40
To: Virtual Research Environment IG (VRE-IG) <***@***.***-groups.org>
Subject: Re: [vre_ig] Virtual Research Environments and Reference Architecture(s) for them
Hi all,
I am unfortunately not going to be in Barcelona but I hope my contributions here helps in the discussions in Barcelona.
Expanding and responding to Leo's comments, I too am of the view that in the research space a single reference architecture is unlikely to have much utility. The diversity across research domains are so vast that we either end up having a reference architecture that is too abstract and vague to be of practical use, or we have a reference architecture that ends up very useful for some domains but not others. My suggestion is we should look at a set of reference architectures that are quite diverse yet well suited to non-overlapping research domains. I feel this way we will be able to have a set of reference architectures that collectively have a broad reach and has good utility.
Another thing that I would like to comment on is that I feel we haven't got a clear understanding of what a VRE is for the purpose of creating Reference Architectures. From my reading, we seem to define VRE as defined by VRE4EIC, and then include Virtual Laboratories and Science Gateways as also being VREs. VRE (as defined by VRE4EIC), VL & Science Gateways, while closely related are also subtly different. I think we would be well served if we develop a clear definition of what we mean by a VRE and then compare and contrast VRE4EIC, VL and Science Gateways against this definition.
I would also like to see this IG not only develop Reference architectures but also develop a set of implementation patterns that are derived from current (successful) implementations of VREs, VLs & SGs that map back to the reference architectures. I believe this would then provide practical guidance to those who are developing VREs for research.
One final comment I'd like to make is that when we consider interoperability we should do so at two levels. Interoperability between e-RIs across domains, and interoperability between e-RIs within a domain. It is important for us to continue to recognise that specilised coupling of e-RI, e-I within a particular research domain is crucial to advancing that field of research and pushing the boundaries of knowledge. I would assert that this should be the primary concern and hence why current investment and effort has been focused around specific domains. However there is also many advantages of having interoperability across domains, and in many respects far more challenging to achieve in practice. So a reference architecture can be of great help.
Kind regards
Kheeran Dharmawardena
--
Full post: https://www.rd-alliance.org/group/virtual-research-environment-ig-vre-ig...
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/55766
--
Full post: https://www.rd-alliance.org/group/virtual-research-environment-ig-vre-ig...
Manage my subscriptions: https://www.rd-alliance.org/mailinglist
Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/55913
--
Hamish Holewa BSc (Comp Sci), BEd, GradDip HEcon
Biodiversity Climate Change Virtual Laboratory Program Manager See our 2016 Year Snapshot www.bccvl.org.au
EcoCloud and RDS Terrestrial Systems Program Manager
Quadrant Project Director and Manager www.quadrant.edu.au
QCIF Project Manager www.qcif.edu.au
***@***.***
+61 (0) 4 000 27 653