Comments about the specifications

09 May 2017

Dear all,

as I will not be able to attend the meeting today, I'm pasting below my
suggestions for the document with the specifications.
Do you think it would be useful if I contribute with some description of
the implementation/use case at GEOFON?

All the best for the call today!

***********************************************

* Why "Collection state" and subdivide in a 3-tuple? It could be better
to remove this extra level. Does it match the JSON structure? No.
* In JSON it is well organized: “id”, “capabilities” and
“properties” are at the same (top) level. It is clear that “membership”
comes later.
* In the Word document it’s less clear: “id” and “state” at the top
level. Then, “membership”, “capabilities” and “metadata” in a second
level; with “properties” as part of “metadata” in a. 3rd level.
* Naming and organization should be coherent through the different
docs and in the graphic. For instance, the concept “metadata” is present
in the Swagger only once “metadataIsMutable”, so what is exactly
“metadata". There we refer to the “properties”. Probably we should
reduce the number of concepts with a formal meaning in the document to
the ones that are used in the JSON representation of the
Collection/Member. So many subdivisions do not help. In the Swagger page
it’s much clear. I would suggest to go for a description in the document
that goes closer to what we have at the Swagger description.
* "The collection membership is a finite set of collection item
identifiers” Probably replace “set” by “group”; or “set/list”
* In "Trait: Insertions allowed”: both operations can be replaced by
“Insert at (index)”
* In “Trait: Shrinkable”: property “no deletes” would lead to a double
negative expression. If needed, replace by "deletes-allowed” or
something similar. But why not to use the “read-only” property?
* What is exactly "Assemble powercollection : Virtual collection
descriptor”?
* There is no need to be so specific in the names of the roles. In fact,
to my understanding that is completely irrelevant for the operation of
such a system. In any case, a user logs in, tries to do something and is
authorized (or not) by the system. We should not mess up the
specification with the “internal management” of the roles (if any). What
if I want a completely open system with “read-only” collections? I need
no AAI system for that. Any user can create a collection and no one can
delete anything. Even the concept of owner could disappear! (I know it’s
extreme).
* And what if instead of roles I would like to have a user-based ACL (no
roles at all)?
* Again, all this could remain internal and implementation specific. We
have no idea how to send the AuthN information to the system. It could
be SSO, but it could also be digest auth, or a code, etc. A client
trying to use the system needs to know *only* how to identify itself
(out of the scope of this document), and which operations exist to be
executed. If the client cannot execute some method, it will receive a
401 http code and it will be clear for it that there is a problem with
permissions.
* Is there a reason why GEOFON is not in the list of use cases? Probably
I’m confused with the exact meaning of “use case” and “implementation”
in the context of this document?

--
Javier Quinteros
-------------------------------------------
2.4/Seismologie
Tel.: +49 (0)331/288-1931
Fax: +49 (0)331/288-1277
Email: javier@gfz-potsdam.de
___________________________________

Helmholtz-Zentrum Potsdam
Deutsches GeoForschungsZentrum GFZ
Stiftung des öff. Rechts Land Brandenburg
Telegrafenberg, 14473 Potsdam

  • Bridget Almas's picture

    Author: Bridget Almas

    Date: 09 May, 2017

    Javier,

    Thank you so much for these helpful comments! And yes, GEOFON should
    definitely be listed as a use case, so please do contribute your
    description.

    All: I'm thinking maybe we should track requested changes to the
    specification document in the GitHub issues list. We could either use
    the apidocs repo and just have a specification label, or create a new
    repository to manage different versions of the spec until it's
    complete. Any objections? Preferences on approach? If we agree, I would
    copy Javier's points to that so we are sure to tackle them.

    Best
    Bridget

    On 05/09/2017 05:51 AM, javier wrote:
    > Dear all,
    >
    > as I will not be able to attend the meeting today, I'm pasting below
    > my suggestions for the document with the specifications.
    > Do you think it would be useful if I contribute with some description
    > of the implementation/use case at GEOFON?
    >
    > All the best for the call today!
    >
    >
    > ***********************************************
    >
    > * Why "Collection state" and subdivide in a 3-tuple? It could be
    > better to remove this extra level. Does it match the JSON structure? No.
    > * In JSON it is well organized: “id”, “capabilities” and
    > “properties” are at the same (top) level. It is clear that
    > “membership” comes later.
    > * In the Word document it’s less clear: “id” and “state” at the
    > top level. Then, “membership”, “capabilities” and “metadata” in a
    > second level; with “properties” as part of “metadata” in a. 3rd level.
    > * Naming and organization should be coherent through the different
    > docs and in the graphic. For instance, the concept “metadata” is
    > present in the Swagger only once “metadataIsMutable”, so what is
    > exactly “metadata". There we refer to the “properties”. Probably we
    > should reduce the number of concepts with a formal meaning in the
    > document to the ones that are used in the JSON representation of the
    > Collection/Member. So many subdivisions do not help. In the Swagger
    > page it’s much clear. I would suggest to go for a description in the
    > document that goes closer to what we have at the Swagger description.
    > * "The collection membership is a finite set of collection item
    > identifiers” Probably replace “set” by “group”; or “set/list”
    > * In "Trait: Insertions allowed”: both operations can be replaced by
    > “Insert at (index)”
    > * In “Trait: Shrinkable”: property “no deletes” would lead to a double
    > negative expression. If needed, replace by "deletes-allowed” or
    > something similar. But why not to use the “read-only” property?
    > * What is exactly "Assemble powercollection : Virtual collection
    > descriptor”?
    > * There is no need to be so specific in the names of the roles. In
    > fact, to my understanding that is completely irrelevant for the
    > operation of such a system. In any case, a user logs in, tries to do
    > something and is authorized (or not) by the system. We should not mess
    > up the specification with the “internal management” of the roles (if
    > any). What if I want a completely open system with “read-only”
    > collections? I need no AAI system for that. Any user can create a
    > collection and no one can delete anything. Even the concept of owner
    > could disappear! (I know it’s extreme).
    > * And what if instead of roles I would like to have a user-based ACL
    > (no roles at all)?
    > * Again, all this could remain internal and implementation specific.
    > We have no idea how to send the AuthN information to the system. It
    > could be SSO, but it could also be digest auth, or a code, etc. A
    > client trying to use the system needs to know *only* how to identify
    > itself (out of the scope of this document), and which operations exist
    > to be executed. If the client cannot execute some method, it will
    > receive a 401 http code and it will be clear for it that there is a
    > problem with permissions.
    > * Is there a reason why GEOFON is not in the list of use cases?
    > Probably I’m confused with the exact meaning of “use case” and
    > “implementation” in the context of this document?
    >

  • Ulrich Schwardmann's picture

    Author: Ulrich Schwardmann

    Date: 09 May, 2017

    Hi,

    do we use a new meeting ID. I still have

    https://app.gotomeeting.com/?meetingId=997874677

    but there seems to be no meeting currently??

    Am 09.05.2017 um 13:47 schrieb balmas:
    > Javier,
    >
    > Thank you so much for these helpful comments! And yes, GEOFON should
    > definitely be listed as a use case, so please do contribute your
    > description.
    >
    > All: I'm thinking maybe we should track requested changes to the
    > specification document in the GitHub issues list. We could either use
    > the apidocs repo and just have a specification label, or create a new
    > repository to manage different versions of the spec until it's
    > complete. Any objections? Preferences on approach? If we agree, I
    > would copy Javier's points to that so we are sure to tackle them.
    >
    > Best
    > Bridget
    >
    > On 05/09/2017 05:51 AM, javier wrote:
    >> Dear all,
    >>
    >> as I will not be able to attend the meeting today, I'm pasting below
    >> my suggestions for the document with the specifications.
    >> Do you think it would be useful if I contribute with some description
    >> of the implementation/use case at GEOFON?
    >>
    >> All the best for the call today!
    >>
    >>
    >> ***********************************************
    >>
    >> * Why "Collection state" and subdivide in a 3-tuple? It could be
    >> better to remove this extra level. Does it match the JSON structure? No.
    >> * In JSON it is well organized: ?EURoeid?EUR?,
    >> ?EURoecapabilities?EUR? and ?EURoeproperties?EUR? are at the same
    >> (top) level. It is clear that ?EURoemembership?EUR? comes later.
    >> * In the Word document it?EUR(tm)s less clear: ?EURoeid?EUR? and
    >> ?EURoestate?EUR? at the top level. Then, ?EURoemembership?EUR?,
    >> ?EURoecapabilities?EUR? and ?EURoemetadata?EUR? in a second level;
    >> with ?EURoeproperties?EUR? as part of ?EURoemetadata?EUR? in a. 3rd
    >> level.
    >> * Naming and organization should be coherent through the
    >> different docs and in the graphic. For instance, the concept
    >> ?EURoemetadata?EUR? is present in the Swagger only once
    >> ?EURoemetadataIsMutable?EUR?, so what is exactly ?EURoemetadata".
    >> There we refer to the ?EURoeproperties?EUR?. Probably we should
    >> reduce the number of concepts with a formal meaning in the document
    >> to the ones that are used in the JSON representation of the
    >> Collection/Member. So many subdivisions do not help. In the Swagger
    >> page it?EUR(tm)s much clear. I would suggest to go for a description
    >> in the document that goes closer to what we have at the Swagger
    >> description.
    >> * "The collection membership is a finite set of collection item
    >> identifiers?EUR? Probably replace ?EURoeset?EUR? by ?EURoegroup?EUR?;
    >> or ?EURoeset/list?EUR?
    >> * In "Trait: Insertions allowed?EUR?: both operations can be replaced
    >> by ?EURoeInsert at (index)?EUR?
    >> * In ?EURoeTrait: Shrinkable?EUR?: property ?EURoeno deletes?EUR?
    >> would lead to a double negative expression. If needed, replace by
    >> "deletes-allowed?EUR? or something similar. But why not to use the
    >> ?EURoeread-only?EUR? property?
    >> * What is exactly "Assemble powercollection : Virtual collection
    >> descriptor?EUR??
    >> * There is no need to be so specific in the names of the roles. In
    >> fact, to my understanding that is completely irrelevant for the
    >> operation of such a system. In any case, a user logs in, tries to do
    >> something and is authorized (or not) by the system. We should not
    >> mess up the specification with the ?EURoeinternal management?EUR? of
    >> the roles (if any). What if I want a completely open system with
    >> ?EURoeread-only?EUR? collections? I need no AAI system for that. Any
    >> user can create a collection and no one can delete anything. Even the
    >> concept of owner could disappear! (I know it?EUR(tm)s extreme).
    >> * And what if instead of roles I would like to have a user-based ACL
    >> (no roles at all)?
    >> * Again, all this could remain internal and implementation specific.
    >> We have no idea how to send the AuthN information to the system. It
    >> could be SSO, but it could also be digest auth, or a code, etc. A
    >> client trying to use the system needs to know *only* how to identify
    >> itself (out of the scope of this document), and which operations
    >> exist to be executed. If the client cannot execute some method, it
    >> will receive a 401 http code and it will be clear for it that there
    >> is a problem with permissions.
    >> * Is there a reason why GEOFON is not in the list of use cases?
    >> Probably I?EUR(tm)m confused with the exact meaning of ?EURoeuse
    >> case?EUR? and ?EURoeimplementation?EUR? in the context of this document?
    >>
    >
    >
    > --
    > Full post:
    > https://www.rd-alliance.org/group/research-data-collections-wg/post/comm...
    > Manage my subscriptions: https://www.rd-alliance.org/mailinglist
    > Stop emails for this post:
    > https://www.rd-alliance.org/mailinglist/unsubscribe/56229
    >

    --
    Mit freundlichem Gruss
    Ulrich Schwardmann

    Phone:+49-551-201-1542 Email:uschwar1@gwdg.de _____ _____ ___
    Gesellschaft fuer wissenschaftliche / __\ \ / / \ / __|
    Datenverarbeitung mbH Goettingen (GWDG) | (_--\ \/\/ /| |) | (_--
    Am Fassberg 11 D-37077 Goettingen Germany \___| \_/\_/ |___/ \___|
    URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de
    Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150
    Geschaeftsfuehrer: Prof. Dr. Ramin Yahyapour
    Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger
    Sitz der Gesellschaft: Goettingen Registergericht: Goettingen
    Handelsregister-Nr. B 598 Zertifiziert nach ISO 9001

  • Frederik Baumgardt's picture

    Author: Frederik Baumgardt

    Date: 09 May, 2017

    Hi Uwe,

    It’s in an hour! 14:00 UTC = 16:00 EST

    Frederik

    > On May 9, 2017, at 9:16 AM, uschwar1 wrote:
    >
    > Hi,
    >
    > do we use a new meeting ID. I still have
    >
    > https://app.gotomeeting.com/?meetingId=997874677
    >
    > but there seems to be no meeting currently??
    >
    >
    > Am 09.05.2017 um 13:47 schrieb balmas:
    >> Javier,
    >>
    >> Thank you so much for these helpful comments! And yes, GEOFON should
    >> definitely be listed as a use case, so please do contribute your
    >> description.
    >>
    >> All: I'm thinking maybe we should track requested changes to the
    >> specification document in the GitHub issues list. We could either use
    >> the apidocs repo and just have a specification label, or create a new
    >> repository to manage different versions of the spec until it's
    >> complete. Any objections? Preferences on approach? If we agree, I
    >> would copy Javier's points to that so we are sure to tackle them.
    >>
    >> Best
    >> Bridget
    >>
    >> On 05/09/2017 05:51 AM, javier wrote:
    >>> Dear all,
    >>>
    >>> as I will not be able to attend the meeting today, I'm pasting below
    >>> my suggestions for the document with the specifications.
    >>> Do you think it would be useful if I contribute with some description
    >>> of the implementation/use case at GEOFON?
    >>>
    >>> All the best for the call today!
    >>>
    >>>
    >>> ***********************************************
    >>>
    >>> * Why "Collection state" and subdivide in a 3-tuple? It could be
    >>> better to remove this extra level. Does it match the JSON structure? No.
    >>> * In JSON it is well organized: ?EURoeid?EUR?,
    >>> ?EURoecapabilities?EUR? and ?EURoeproperties?EUR? are at the same
    >>> (top) level. It is clear that ?EURoemembership?EUR? comes later.
    >>> * In the Word document it?EUR(tm)s less clear: ?EURoeid?EUR? and
    >>> ?EURoestate?EUR? at the top level. Then, ?EURoemembership?EUR?,
    >>> ?EURoecapabilities?EUR? and ?EURoemetadata?EUR? in a second level;
    >>> with ?EURoeproperties?EUR? as part of ?EURoemetadata?EUR? in a. 3rd
    >>> level.
    >>> * Naming and organization should be coherent through the
    >>> different docs and in the graphic. For instance, the concept
    >>> ?EURoemetadata?EUR? is present in the Swagger only once
    >>> ?EURoemetadataIsMutable?EUR?, so what is exactly ?EURoemetadata".
    >>> There we refer to the ?EURoeproperties?EUR?. Probably we should
    >>> reduce the number of concepts with a formal meaning in the document
    >>> to the ones that are used in the JSON representation of the
    >>> Collection/Member. So many subdivisions do not help. In the Swagger
    >>> page it?EUR(tm)s much clear. I would suggest to go for a description
    >>> in the document that goes closer to what we have at the Swagger
    >>> description.
    >>> * "The collection membership is a finite set of collection item
    >>> identifiers?EUR? Probably replace ?EURoeset?EUR? by ?EURoegroup?EUR?;
    >>> or ?EURoeset/list?EUR?
    >>> * In "Trait: Insertions allowed?EUR?: both operations can be replaced
    >>> by ?EURoeInsert at (index)?EUR?
    >>> * In ?EURoeTrait: Shrinkable?EUR?: property ?EURoeno deletes?EUR?
    >>> would lead to a double negative expression. If needed, replace by
    >>> "deletes-allowed?EUR? or something similar. But why not to use the
    >>> ?EURoeread-only?EUR? property?
    >>> * What is exactly "Assemble powercollection : Virtual collection
    >>> descriptor?EUR??
    >>> * There is no need to be so specific in the names of the roles. In
    >>> fact, to my understanding that is completely irrelevant for the
    >>> operation of such a system. In any case, a user logs in, tries to do
    >>> something and is authorized (or not) by the system. We should not
    >>> mess up the specification with the ?EURoeinternal management?EUR? of
    >>> the roles (if any). What if I want a completely open system with
    >>> ?EURoeread-only?EUR? collections? I need no AAI system for that. Any
    >>> user can create a collection and no one can delete anything. Even the
    >>> concept of owner could disappear! (I know it?EUR(tm)s extreme).
    >>> * And what if instead of roles I would like to have a user-based ACL
    >>> (no roles at all)?
    >>> * Again, all this could remain internal and implementation specific.
    >>> We have no idea how to send the AuthN information to the system. It
    >>> could be SSO, but it could also be digest auth, or a code, etc. A
    >>> client trying to use the system needs to know *only* how to identify
    >>> itself (out of the scope of this document), and which operations
    >>> exist to be executed. If the client cannot execute some method, it
    >>> will receive a 401 http code and it will be clear for it that there
    >>> is a problem with permissions.
    >>> * Is there a reason why GEOFON is not in the list of use cases?
    >>> Probably I?EUR(tm)m confused with the exact meaning of ?EURoeuse
    >>> case?EUR? and ?EURoeimplementation?EUR? in the context of this document?
    >>>
    >>
    >>
    >> --
    >> Full post:
    >> https://www.rd-alliance.org/group/research-data-collections-wg/post/comm...
    >> Manage my subscriptions: https://www.rd-alliance.org/mailinglist
    >> Stop emails for this post:
    >> https://www.rd-alliance.org/mailinglist/unsubscribe/56229
    >>
    >
    > --
    > Mit freundlichem Gruss
    > Ulrich Schwardmann
    >
    > Phone:+49-551-201-1542 Email:uschwar1@gwdg.de _____ _____ ___
    > Gesellschaft fuer wissenschaftliche / __\ \ / / \ / __|
    > Datenverarbeitung mbH Goettingen (GWDG) | (_--\ \/\/ /| |) | (_--
    > Am Fassberg 11 D-37077 Goettingen Germany \___| \_/\_/ |___/ \___|
    > URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de
    > Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150
    > Geschaeftsfuehrer: Prof. Dr. Ramin Yahyapour
    > Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger
    > Sitz der Gesellschaft: Goettingen Registergericht: Goettingen
    > Handelsregister-Nr. B 598 Zertifiziert nach ISO 9001
    >
    >
    >
    >
    > --
    > Full post: https://www.rd-alliance.org/group/research-data-collections-wg/post/comm...
    > Manage my subscriptions: https://www.rd-alliance.org/mailinglist
    > Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/56229

  • Ulrich Schwardmann's picture

    Author: Ulrich Schwardmann

    Date: 09 May, 2017

    Thanks Frederik,

    yes, it's summertime now, even if it still seems to be winter here:-)

    Am 09.05.2017 um 15:18 schrieb fbaumgardt:
    > Hi Uwe,
    >
    > It’s in an hour! 14:00 UTC = 16:00 EST
    >
    > Frederik
    >
    >> On May 9, 2017, at 9:16 AM, uschwar1 wrote:
    >>
    >> Hi,
    >>
    >> do we use a new meeting ID. I still have
    >>
    >> https://app.gotomeeting.com/?meetingId=997874677
    >>
    >> but there seems to be no meeting currently??
    >>
    >>
    >> Am 09.05.2017 um 13:47 schrieb balmas:
    >>> Javier,
    >>>
    >>> Thank you so much for these helpful comments! And yes, GEOFON should
    >>> definitely be listed as a use case, so please do contribute your
    >>> description.
    >>>
    >>> All: I'm thinking maybe we should track requested changes to the
    >>> specification document in the GitHub issues list. We could either use
    >>> the apidocs repo and just have a specification label, or create a new
    >>> repository to manage different versions of the spec until it's
    >>> complete. Any objections? Preferences on approach? If we agree, I
    >>> would copy Javier's points to that so we are sure to tackle them.
    >>>
    >>> Best
    >>> Bridget
    >>>
    >>> On 05/09/2017 05:51 AM, javier wrote:
    >>>> Dear all,
    >>>>
    >>>> as I will not be able to attend the meeting today, I'm pasting below
    >>>> my suggestions for the document with the specifications.
    >>>> Do you think it would be useful if I contribute with some description
    >>>> of the implementation/use case at GEOFON?
    >>>>
    >>>> All the best for the call today!
    >>>>
    >>>>
    >>>> ***********************************************
    >>>>
    >>>> * Why "Collection state" and subdivide in a 3-tuple? It could be
    >>>> better to remove this extra level. Does it match the JSON structure? No.
    >>>> * In JSON it is well organized: ?EURoeid?EUR?,
    >>>> ?EURoecapabilities?EUR? and ?EURoeproperties?EUR? are at the same
    >>>> (top) level. It is clear that ?EURoemembership?EUR? comes later.
    >>>> * In the Word document it?EUR(tm)s less clear: ?EURoeid?EUR? and
    >>>> ?EURoestate?EUR? at the top level. Then, ?EURoemembership?EUR?,
    >>>> ?EURoecapabilities?EUR? and ?EURoemetadata?EUR? in a second level;
    >>>> with ?EURoeproperties?EUR? as part of ?EURoemetadata?EUR? in a. 3rd
    >>>> level.
    >>>> * Naming and organization should be coherent through the
    >>>> different docs and in the graphic. For instance, the concept
    >>>> ?EURoemetadata?EUR? is present in the Swagger only once
    >>>> ?EURoemetadataIsMutable?EUR?, so what is exactly ?EURoemetadata".
    >>>> There we refer to the ?EURoeproperties?EUR?. Probably we should
    >>>> reduce the number of concepts with a formal meaning in the document
    >>>> to the ones that are used in the JSON representation of the
    >>>> Collection/Member. So many subdivisions do not help. In the Swagger
    >>>> page it?EUR(tm)s much clear. I would suggest to go for a description
    >>>> in the document that goes closer to what we have at the Swagger
    >>>> description.
    >>>> * "The collection membership is a finite set of collection item
    >>>> identifiers?EUR? Probably replace ?EURoeset?EUR? by ?EURoegroup?EUR?;
    >>>> or ?EURoeset/list?EUR?
    >>>> * In "Trait: Insertions allowed?EUR?: both operations can be replaced
    >>>> by ?EURoeInsert at (index)?EUR?
    >>>> * In ?EURoeTrait: Shrinkable?EUR?: property ?EURoeno deletes?EUR?
    >>>> would lead to a double negative expression. If needed, replace by
    >>>> "deletes-allowed?EUR? or something similar. But why not to use the
    >>>> ?EURoeread-only?EUR? property?
    >>>> * What is exactly "Assemble powercollection : Virtual collection
    >>>> descriptor?EUR??
    >>>> * There is no need to be so specific in the names of the roles. In
    >>>> fact, to my understanding that is completely irrelevant for the
    >>>> operation of such a system. In any case, a user logs in, tries to do
    >>>> something and is authorized (or not) by the system. We should not
    >>>> mess up the specification with the ?EURoeinternal management?EUR? of
    >>>> the roles (if any). What if I want a completely open system with
    >>>> ?EURoeread-only?EUR? collections? I need no AAI system for that. Any
    >>>> user can create a collection and no one can delete anything. Even the
    >>>> concept of owner could disappear! (I know it?EUR(tm)s extreme).
    >>>> * And what if instead of roles I would like to have a user-based ACL
    >>>> (no roles at all)?
    >>>> * Again, all this could remain internal and implementation specific.
    >>>> We have no idea how to send the AuthN information to the system. It
    >>>> could be SSO, but it could also be digest auth, or a code, etc. A
    >>>> client trying to use the system needs to know *only* how to identify
    >>>> itself (out of the scope of this document), and which operations
    >>>> exist to be executed. If the client cannot execute some method, it
    >>>> will receive a 401 http code and it will be clear for it that there
    >>>> is a problem with permissions.
    >>>> * Is there a reason why GEOFON is not in the list of use cases?
    >>>> Probably I?EUR(tm)m confused with the exact meaning of ?EURoeuse
    >>>> case?EUR? and ?EURoeimplementation?EUR? in the context of this document?
    >>>>
    >>>
    >>> --
    >>> Full post:
    >>> https://www.rd-alliance.org/group/research-data-collections-wg/post/comm...
    >>> Manage my subscriptions: https://www.rd-alliance.org/mailinglist
    >>> Stop emails for this post:
    >>> https://www.rd-alliance.org/mailinglist/unsubscribe/56229
    >>>
    >> --
    >> Mit freundlichem Gruss
    >> Ulrich Schwardmann
    >>
    >> Phone:+49-551-201-1542 Email:uschwar1@gwdg.de _____ _____ ___
    >> Gesellschaft fuer wissenschaftliche / __\ \ / / \ / __|
    >> Datenverarbeitung mbH Goettingen (GWDG) | (_--\ \/\/ /| |) | (_--
    >> Am Fassberg 11 D-37077 Goettingen Germany \___| \_/\_/ |___/ \___|
    >> URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de
    >> Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150
    >> Geschaeftsfuehrer: Prof. Dr. Ramin Yahyapour
    >> Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger
    >> Sitz der Gesellschaft: Goettingen Registergericht: Goettingen
    >> Handelsregister-Nr. B 598 Zertifiziert nach ISO 9001
    >>
    >>
    >>
    >>
    >> --
    >> Full post: https://www.rd-alliance.org/group/research-data-collections-wg/post/comm...
    >> Manage my subscriptions: https://www.rd-alliance.org/mailinglist
    >> Stop emails for this post: https://www.rd-alliance.org/mailinglist/unsubscribe/56229
    >
    > --
    > Full post:
    > https://www.rd-alliance.org/group/research-data-collections-wg/post/comm...
    > Manage my subscriptions: https://www.rd-alliance.org/mailinglist
    > Stop emails for this post:
    > https://www.rd-alliance.org/mailinglist/unsubscribe/56229
    >

    --
    Mit freundlichem Gruss
    Ulrich Schwardmann

    Phone:+49-551-201-1542 Email:uschwar1@gwdg.de _____ _____ ___
    Gesellschaft fuer wissenschaftliche / __\ \ / / \ / __|
    Datenverarbeitung mbH Goettingen (GWDG) | (_--\ \/\/ /| |) | (_--
    Am Fassberg 11 D-37077 Goettingen Germany \___| \_/\_/ |___/ \___|
    URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de
    Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150
    Geschaeftsfuehrer: Prof. Dr. Ramin Yahyapour
    Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger
    Sitz der Gesellschaft: Goettingen Registergericht: Goettingen
    Handelsregister-Nr. B 598 Zertifiziert nach ISO 9001

submit a comment