[Moims-dai] Component Diagram - Consumer and Producer Application Update

Wed May 20 17:59:38 UTC 2020

That was just intended as an example, albeit maybe a poor example.  Several DAI folks, me included, had telecons with LOTAR folks (at their request) in March.  If memory serves me right, in the OAIS-IF overview, I even suggested that LOTAR might arrange for the development of an “enterprise data” plug-in, for the data types that LOTAR is concerned with.  Didn’t get much reaction from that, and went on to other preservation topics.  

So…  I should instead use an example of an ISO 10303 plug-in?  Is there a candidate organization that might develop that for the community?  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA 

From: Kjell Bengtsson <Kjell.Bengtsson at jotne.com> 
Sent: Wednesday, May 20, 2020 7:18 AM
To: kearneysolutions at gmail.com; 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org>
Cc: 'Lin, Dawei (NIH/NIAID) [E]' <dawei.lin at nih.gov>; 'Hughes, John S (US 398B)' <john.s.hughes at jpl.nasa.gov>
Subject: RE: [Moims-dai] Component Diagram - Consumer and Producer Application Update

Hi Mike, 

*	  So an engineering archive might say “for my engineering data you need my engineering plugin and Autodesk’s Autocad plugin.”  

Probably not. Most people in the Engineering Community is looking for a no-vendor lock-in of data. Today more than 80% of all CAD data exchange is using ISO 10303 (STEP) and similar for the Building Industry uses the OpemBIM/IFC ISO standards. So any application with such read/write/validate capability (or call it plugin) should be able to open the ISO/STEP/BIM format. 

Most relevant for this discussion is to have a look at  <http://www.lotar-international.org/> LOTAR International for archiving of Engineering data, using the ISO 10303 (CAD/CAE/TEST/PLM/ILS/Sensor) ISO 16739 (BIM) standards for data exchange, sharing and archiving.

Currently, Jotne is tasked by the Norwegian National Archive to do a study for how to archive BIM/IFC data which since now is a law in Norway, “FOR-2017-12-19-2286”. 

Best regards, Kjell 

From: kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com>  [mailto:kearneysolutions at gmail.com] 
Sent: tirsdag 19. mai 2020 17.17
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Cc: 'Lin, Dawei (NIH/NIAID) [E]' <dawei.lin at nih.gov <mailto:dawei.lin at nih.gov> >; 'Hughes, John S (US 398B)' <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Subject: Re: [Moims-dai] Component Diagram - Consumer and Producer Application Update

Hey, Dawei, glad to have your input in any form you can provide it.  

In the architecture concept, we have plug-ins or bindings that are specific to each archive (Science, Engineering, DNA, Geology are just examples) or in some cases to each data format (PDF, HTML are just examples).  If some archive wanted to have a “research” plug-in/binding that combined Science and Engineering, that would be perfectly OK.  But it is up to the archive to define the scope of each plugin that is needed to access their archive.  

The idea with some plugins being data formats rather than archive (designated community) specific was so that some commercial vendors can help the archive by publishing a plug-in for their complex software.  Like Adobe might produce a PDF plugin, Autodesk might publish an Autocad plugin, etc.  These would be supplemental to the main plugin needed for an archive.  So an engineering archive might say “for my engineering data you need my engineering plugin and Autodesk’s Autocad plugin.”  

We discussed your comment, and we think that Steve will change “Binding” on his diagram to “Binding Layer” and that will make it more clear that the box is not actually a binding, but a layer that can be composed of many types of bindings, with only a few examples shown.  

Does that address your comment?  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA 

From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org <mailto:moims-dai-bounces at mailman.ccsds.org> > On Behalf Of Lin, Dawei (NIH/NIAID) [E] via MOIMS-DAI
Sent: Monday, May 18, 2020 4:52 PM
To: MOIMS-Data Archive Interoperability <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Cc: Lin, Dawei (NIH/NIAID) [E] <dawei.lin at nih.gov <mailto:dawei.lin at nih.gov> >; Hughes, John S (US 398B) <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Subject: Re: [Moims-dai] Component Diagram - Consumer and Producer Application Update

Hi Steve,

   Sorry that I have not been able to participate in the weekly calls because of a conflict of another regular call. 

   From the perspective of not knowing the context, I think that “research data” sounds more general than “scientific data” and “engineering data” in Component_Diagram_200518.jpg, which may be useful to describe a broad concept.  Also, depending on the definition of “Science Data”, it may need the same implementation of “Native Archive” as the “Engineering Data” does. But again, I did not participate in a lot of discussions, so what I said is entirely off. 

   Thank you,

   Dawei

Dawei Lin, Ph.D.

Associate Director for Bioinformatics and Senior Advisor to the Director

Division of Allergy, Immunology, and Transplantation

National Institute of Allergy and Infectious Diseases

5601 Fisher’s Lane 7A70, MSC 9828

Rockville MD, 20852

Work phone: 240-627-3527

Cell Phone: 301-312-3986

From: "Hughes, John S (US 398B) via MOIMS-DAI" <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Reply-To: MOIMS-Data Archive Interoperability <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Date: Monday, May 18, 2020 at 12:40 PM
To: MOIMS-Data Archive Interoperability <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Cc: "Hughes, John S (US 398B)" <john.s.hughes at jpl.nasa.gov <mailto:john.s.hughes at jpl.nasa.gov> >
Subject: [Moims-dai] Component Diagram - Consumer and Producer Application Update

Hi all,

Attached is the latest version of a Component diagram that maps to Mike’s diagram. 

Thanks,

Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20200520/b2cd1b16/attachment-0001.htm>