[Moims-dai] OAIS and the OAIS Architecture

Mon Mar 12 20:36:23 UTC 2018

Comments embedded below.  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

From: MOIMS-DAI [mailto:moims-dai-bounces at mailman.ccsds.org] On Behalf Of Mark Conrad
Sent: Monday, March 12, 2018 12:36 PM
To: MOIMS-Data Archive Ingestion <moims-dai at mailman.ccsds.org>
Subject: Re: [Moims-dai] OAIS and the OAIS Architecture

I will preface my remarks by saying that I am not sure I understand many of the points/distinctions that are being made in the document Mike sent around. I think it would be very helpful to have a specific example of (parts) of the architecture and example implementations so that we are all talking apples-to-apples.

A few comments:

"To extend an archive’s capabilities further, a trustworthy repository can also implement compliance with the Data Archive Architecture and protocol (or plugin/binding/API/whatever) and can then cite that it is a trusted archive that is interoperable with other entities (archives, providers, consumers)."

Maybe I don't understand how you are defining inter-operability. By definition an OAIS has to be able to interact with its providers and the consumers in its Designated Community. What other interoperation are you proposing for the producers and consumers in its Designated Community?

[>>MK: ] 

*         Same user interface for multiple archives from multiple sources for members of a designated community.

*         Same user interface for individuals who are members of multiple designated communities.  

*         Same user interface for researchers who are accessing multiple other designated communities

*         Same user interface for the public when the public has been granted access to designated communities’ archives

*         Ubiquitous and well-known interfaces so that researchers generations from now will know what software/access method was used in prior generations.

*         Basically a consistent and ubiquitous access method benefits all users of archives, both known and expected users (current members of designated communities) and surprising and unexpected users (peripheral users, cross-discipline researchers, investigative reporters, public.)  

"The “second stage” is to move on to interoperable systems, architecture and protocols, with those processes as the foundation."

Interoperability with another OAIS is a feature that an OAIS may or may not want to support. It is important to remember that the OAIS responds to the needs of its Designated Community and its resource allocators. These groups may or may not be interested in interoperability with other OAISs (especially if that interoperability comes with additional costs). 

[>>MK: ] I have been largely focusing on consistent user (producer and consumer) interfaces, because interoperability for users is where the most important benefits come in.  Long-term preservation should account for a future user community that is not the same personnel as the current members of a designated community.  However, interoperability between archives is obviously important. Steve may have already been addressing that in his modeling effort… not sure.  

[>>MK: ] In terms of additional costs, if the interoperability capabilities come from the same interoperability “framework”, they gain the cost efficiency that comes from standardization of access methods… software reuse, etc.  

"But don’t hold your breath, because many CCSDS WGs have talked about that “gold standard” interoperability certification capability, but none have accomplished it."

Interoperability with what, precisely?

[>>MK: ] When other protocol standards have been established, the requirement is that producers of products that comply with the standard should be interoperable with other products that comply with the standard.  When resources are available, the standards body may set up a “gold standard” implementation and host it online, against which other protocol vendors or producers can test their implementation to prove its interoperability with the standard.  If they pass the test of interoperating with the “gold standard <https://www.qualitylogic.com/testing-solutions/interoperability-testing/> ” then they implemented it correctly.  I was simply saying that conceivably a protocol test suite could be hosted by a standards body to either developers of user access softer or developers of archives could test their implementation against the standard.  

"5.        However, the Interoperable protocols (or bindings or APIs) are requirements imposed on an archive database implementation (An “implementation” based on Oracle or MySQL or another RDBMS).  Or on an AIP implementation.  The database and the AIP design must comply with the communication formats at the protocol interface or API but they can implement with various underlying structures."

Maybe I am misunderstanding your text. It appears to me that the architecture would already be constraining the OAIS infrastructure if it is to be limited to RDBMS.  There are many repositories out there that are using NoSql databases and other tools for managing their digital objects. I am also not sure what is meant by "communication formats."

[>>MK: ] There will be some constraining to the infrastructure that archive implementers develop.  That’s required in order to achieve interoperable systems.  It doesn’t *constrain* OAIS, it *supports* OAIS.  But it constrains implementations of OAIS archives.  My example wasn’t intended to limit underlying implementations to RDBMS or anything else… I was trying to say the opposite.  An underlying RDBMS or MySQL or NoSQL or flat-file database or Matrioshka brain <https://en.wikipedia.org/wiki/Matrioshka_brain> , or whatever can be used, but it has to talk to the user interface with either the interaction patterns defined by a protocol or an interface defined by an API.  By “communications formats” I was talking precisely about those interactions or interfaces.  

"Yes, to the OAIS RM, the Data Archive Architecture prescribed (normative) in the DA ADD looks like one of many possible architectural “implementations.”  But it’s not an implementation to the protocols or the archive implementers, it’s another (albeit lower) set of requirements.  So let’s not call it an implementation.  It’s an architecture."

The way I read this is that the goal is an architecture that would limit the possible implementations an OAIS could pursue. What am I getting wrong?

[>>MK: ] It is indeed limiting an aspect of the OAIS implementations… the communications or interface aspect.  Underneath the interface and beyond the protocol, processing can exercise a variety of inventive implementations.  This is the way that the Service Oriented Architecture of SM&C performs, if it help to have a current example.  Lots of application freedom, but when they approach the wall where they communicate with the outside world, protocols and formats constrain that interface.  

"Personally, I think the architecture completes an incomplete OAIS, hence should be called (named) OAIS."

What is it that you see as lacking? Interoperability? With what?

[>>MK: ] Primarily (my view) interoperability with standard user interfaces for producers and consumers.  I think this is critically important for long-term preservation because a long time from now that ubiquitous well-understood standard consumer interface should have been passed on to future generations to improve the chances for flawless access to preserved data.  As you pointed out, interoperability with other archives (or among distributed archives) is also an important topic.  

My two cents for now. My brain hurts!

Mark

On Sun, Mar 11, 2018 at 9:18 PM, Mike Kearney <kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com> > wrote:

In terms of the naming convention for the architecture… I would like to keep this as an open discussion for a while longer.  The term “Framework” is quite a bit overused nowadays (The CCSDS management “framework” for example).  

My opinion was that OAIS would benefit from an interoperable architecture, but if the group wants to have a terminology divide between OAIS and this digital preservation architecture, then so be it.  I would encourage the group to discuss this a bit further, though.  

Bob, your discussion about whether there can be multiple frameworks for OAIS interoperability…  If the multiple frameworks are not interoperable with each other… that would be a really bad thing.  Similar to having two OAIS Reference Models that contradict each other.  And if the multiple frameworks for OAIS interoperability are interoperable with each other…  I think that’s one framework, not two.  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

From: MOIMS-DAI [mailto:moims-dai-bounces at mailman.ccsds.org <mailto:moims-dai-bounces at mailman.ccsds.org> ] On Behalf Of Robert Downs
Sent: Sunday, March 11, 2018 3:29 PM
To: MOIMS-Data Archive Ingestion <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] OAIS and the OAIS Architecture

I agree with Bruce's concerns and believe that we need to be very careful that proposing and naming a new design artifact does not cause confusion. I also agree with John's concerns and believe that it should be done in a way that does not imply that a proposed design artifact is a requirement for certification of OAIS compliance. Using a term like OAIS Interoperability Framework, which David proposed, might be a step in the right direction, as compared to the earlier term. However, considering the variety of diverse communities that have embraced the OAIS Reference Model, I wonder whether using a term, such as OAIS Interoperability Framework, would imply that there is no room for other frameworks for OAIS interoperability. 

Thanks,

Bob

Robert R. Downs, PhD
Senior Digital Archivist and Senior Staff Associate Officer of Research
Acting Head of Cyberinfrastructure and Informatics Research and Development
Center for International Earth Science Information Network (CIESIN),
The Earth Institute, Columbia University
P.O. Box 1000, 61 Route 9W, Palisades, NY 10964 USA
Voice: 845-365-8985 <tel:(845)%20365-8985> ; fax: 845-365-8922 <tel:(845)%20365-8922> 
E-mail: rdowns at ciesin.columbia.edu <mailto:rdowns at ciesin.columbia.edu> 
Columbia University CIESIN Web site: http://www.ciesin.columbia.edu
ORCID: 0000-0002-8595-5134

On Sun, Mar 11, 2018 at 3:07 PM, John Garrett <garrett at his.com <mailto:garrett at his.com> > wrote:

Hi,

That sounds good to me.

I agree that OAIS Architecture sounds too much like it is a required architecture to be OAIS compliant. 

It also then starts to be misunderstood as required to be certified.

However OAIS-Interoperability Framework sounds less like a requirement and more like a desirable feature that archives would want.

Peace and joy,

-JOhn  

From: MOIMS-DAI [mailto:moims-dai-bounces at mailman.ccsds.org <mailto:moims-dai-bounces at mailman.ccsds.org> ] On Behalf Of David Giaretta
Sent: Sunday, March 11, 2018 1:22 PM
To: 'MOIMS-Data Archive Ingestion' <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] OAIS and the OAIS Architecture

Would it be better to call the new work an OAIS Interoperability Framework (OAIS-IF)

..David

From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org <mailto:moims-dai-bounces at mailman.ccsds.org> > On Behalf Of Mike Kearney
Sent: 11 March 2018 03:29
To: 'MOIMS-Data Archive Ingestion' <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: [Moims-dai] OAIS and the OAIS Architecture

DAI WG members:  After last Tuesday’s discussion, I realized that we have an issue at least with terminology for the new architecture effort.  So I’m attaching a short writeup for your reading pleasure and discussion during the next telecon.  

The main points you should take away from this discussion are:  

*        The use of the term “OAIS Architecture” should not be considered intended to change anything about the OAIS Reference Model or certification thereof, and;

*        If use of the term “OAIS Architecture” make people think it will change OAIS, then maybe we need a new term.  

I would prefer to stick with “OAIS Architecture,” but we can discuss other options.  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

_______________________________________________
MOIMS-DAI mailing list
MOIMS-DAI at mailman.ccsds.org <mailto:MOIMS-DAI at mailman.ccsds.org> 
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai

_______________________________________________
MOIMS-DAI mailing list
MOIMS-DAI at mailman.ccsds.org <mailto:MOIMS-DAI at mailman.ccsds.org> 
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20180312/a89151da/attachment.html>