[Moims-dai] Comments on today's telecon (12/10)

[kearneysolutions at gmail.com]

I had a few other things I wanted to say/document, which we can discuss on
email or at a future telecon.  

 

We had a discussion about whether the interoperability framework includes
*only* functions in the OAIS Information Model, or *also* things that are
outside the information model but within the OAIS Reference model.  Reports
on SIP (or AIP?) contents for virus scanning or CRCs were examples.  We
tried to explain that away as being inside provenance, hence handled at the
user interface as provenance, hence within the information model.  But if it
is not handled as provenance, i.e. if it is not in the information model,
then we've got a potential "hole" in the interoperability architecture if it
is not included as a specific function in the architecture.  Similarly, we
discussed that there may be things external to the AIP, yet having a
relationship to the AIP, such as logs.  Logs (we agreed, I think) are not
included in the AIP, and are not in the information model.  Do they surface
at the interoperability interface?  

 

I may have misunderstood, but I think this discussion of inside/outside of
the info model or interoperability framework is an open question for future
discussion.  Steve, if you think this was resolved, let us know.  

 

It might be interesting to see how SM&C handled this.  Do they have
"reports" as part of their user interface?  

 

One step further. I think if those reports (submission reports, virus scan
reports, logs, etc.) are human-readable PDF reports, then they don't need to
be part of the interoperability interface (I know. there may need to be
agreement on human language, but I think that can be handled completely
outside of the interoperability architecture).  If those reports are machine
readable software constructs sent to a user interface application (like an
application display or other communications construct) then they do need to
be part of the interoperability interface.  I think John commented (and
agreed, I think) on this point when he mentioned something like "only
communication protocols".  

 

We kept using the "user interface" (producer/consumer interface) as the
example of where salient interoperability features would surface, and hence
what needed to be defined in the interoperability framework architecture.
However, there are more interfaces.  (1) between the user interface and the
abstraction layer, (2) between the abstraction layer and the plugin/binding,
(3) between the plugin/binding and the archive.  We need those defined in
the architecture as well, because this is a layered/modular interoperability
architecture.  Therefore, features that affect interoperability at any of
those interfaces need to be described in Steve's architecture model and
architecture document. 

 

Terry brought up (again, I think) the question of how interfaces between
archives are handled.  In the past, I thought we agreed that
archive-to-archive interfaces would utilize the same interfaces as producers
and consumers.  An archive sending data to another archive uses the
"producer interface" of the receiving archive, and sends SIPs.  And a
submission agreement is sent in advance.  I suppose that if the submission
agreement accommodates it, the sending archive could alternatively send
DIPs.  In any case, no "special" interface was needed for transactions
between archives.  An archive viewed another archive as just another
producer or consumer.  Steve, this question has come up several times, so if
this is our approach, it should probably be documented in the introduction
of the architecture document.   

 

Those are my thoughts after today's discussion.  

 

   -=- Mike

 

Mike Kearney

Huntsville, Alabama, USA 

 

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