[Moims-dai] Notes from DAI Webex meeting 21st Feb 2017

Sat Feb 25 11:35:15 UTC 2017

Notes from DAI Webex meeting 21st Feb 2017

1.	Status of the Report to CMC on status of DAI WG Future  updated
version based on discussion last week
https://www.dropbox.com/s/wnsbpu67qf81jfj/MOIMS-DAI%20WG%20Report%20to%20the
%20CMC%20MOIMS-v5.docx?dl=0 and updated PPT
https://www.dropbox.com/s/9ek0krl6pp9ysnd/Basic%20Archive%20Architecture%20C
oncept%20-%20v4%20for%20CMC.pptx?dl=0

*	Delivery will now be 1st March 
*	MK: typos: P1 grounf vs ground, P4: ;last sub-bullet -"retried" vs
"retrieved" 
*	MK: question: P1, para 5: Keep more of original wording 
*	MH: Add terms like "reproducability" and "re-use" after Fig 1. Maybe
also reproduce Fig 1 after the schedule adding in re-use 
*	MK - also add some of that flavour to Q4 
*	Schedule: start with GB then maybe add MB later - JGG will change
CWE to be GB 
*	The document tree can be discussed at San Antonio 
*	"Return on Investment" 
*	But keep last para on resources - put in next steps area 

2.	IPELTU see latest doc at
https://www.dropbox.com/s/pcb9fwkk6uaxr69/6NNxN-M-0x6-ILF-latest-version.doc
x?dl=0 - You will notice there are quite a few changes ( 15 Minutes)

*	Use the definition of PHASE from PMBOK and clarify the text 
*	Update section 5 to make the matrix more readable and consistent
with the PMBOK approach - still need work for consistency 
*	Remove the details of LTDP and add to the block diagram of phases
(the diagram has been corrected from last week  one of blocks had the wrong
color 

3.	OAIS Update (and ISO 16363 Update) (http://review.oais.info/) (35
Minutes) Work on Suggested Changes

*	Advanced consideration: 135
http://review.oais.info/show_bug.cgi?id=135 

*	Matthias suggested a way of discussing distributed archives:

Functional Entity: a set of services and functions that servers a specific
need.

Functional Entity Area: a set of Functional Entities.

6.1.5 Virtual Archives with Distributed Functional Areas or Functional
Entities

In an association involving Archives with a distributed Functional Entity
Area or Functional Entity, Management has entered into agreements with other
Archives to link or integrate their distributed Functional Areas or
Functional Entities with each other in a complementary way. The motive for
this may be to distribute resources in a complementary way in order to
achieve the complete set of functional entities to establish a Virtual
Archive in a complementary collaborative way.  This association is
fundamentally different from the previous examples, in that it does not only
federate, share or cooperate w.r.t. Functional Areas but really distributes
them in accordance with Competences and Capacities of contributing Archives.

Figure 6-5 (xxx to be established XXX) illustrates the distribution of a
Functional XXX, consisting of an XXX entity and a  YYY entity, between
several Archives, OAIS 1 until OAIS n.  The XXX and YYY facilities can be at
any of the previously described levels of interoperability.  In fact, each
Archive can serve very independent communities as implied in this figure.
However, for the common XXX element to succeed, standards are needed at the
internal XXX-YYY and YYY-XXX interfaces. 

Additional potential distributed Functional Entities include, e.g.,
registries of Representation Information and name resolvers such as the DNS.
In the former case, a registry of Representation Information should also be
an OAIS and the Representation Information it holds should be part of the
Content Information it holds. The Representation Information it holds might,
for example, be part of the Representation Network for the Content
Information within an AIP in another OAIS. In such a case the OAIS holding
that AIP may cache copies of the Representation Network held in the
registry. Whether it does so or instead relies on the registry to maintain
the Representation Network, the ultimate responsibility for the
understandability of the Content Information remains with the OAIS which
holds the AIP.

*	from 2 weeks ago  we had hoped these will be quicker to resolve but
we did not finish and the following were not resolved 

*	97 - agreed by DAI - waiting response from Stéphane Reecht 
*	212 - deferred until discussion on Roadmap 
*	121 - new inputs received from Giovanni 
*	30  Terry has suggested text 
*	75 - Terry has suggested text: 

This is similar to changes recommended in Item 30 for Section 2.2 OAIS
information. 

The issue has ramifications beyond what's stated in the follow on comments.
Part of the problem is that the original wording implied that CI included
physical properties of the basic underlying storage devices, while later
comments suggest that the logical structure was more likely to be what was
known to the Repository. In many cases, information collected in remote
sensing or high energy physics by sensors or detectors must include
essentially all of the physical properties of the sensor and how the
collected data is mapped to the storage subsystem(s), if later advances in
science are going to allow re-examination and new findings from data
collected in a previous epoch. 

Suggested new wording (expanding upon Mark Conrad's original): 

"If media-dependent attributes have been included as part of the Content
Information, a way must be found to preserve this information when migrating
to media with different storage architectures. Media may be either portable
or fixed, and the mechanics of migration will vary depending upon similarity
or differences between the originating and receiving medium. Contemporary
devices as of this writing (e.g., memory sticks, CDs, DVDs), obsolescent or
obsolete devices (7-track tapes, 'core' memory) may be permanently or
semi-permanently attached to a computer system, or completely portable and
easily transported between locations. So, depending on if Content
information describes a holding in terms of physical properties (such as
sector size or physical record length) or logical properties (such as
internal volume label or relational DB schema) a migration must be able to
represent that same information on the receiving medium" 

*	From last week 

*	102  awaiting response from Mark 
*	130  awaiting Marks response to Terry suggested text: 

I've tried to retain the intent of the original, while rewording the
implementation oriented specifics to be more abstract. 

"The Coordinate Access Activities function provides one or more interfaces
to the information holdings of the Archive. Such interfaces are documented
as procedures which allow external agents to communicate with the
repository. External agents could be persons or systems outside of the
administrative boundaries of the repository (in contrast with internal
functions and personnel of the repository itself). Each interface may be
fully or semi-automated or completely non-automated (as in the case of a
walk-in counter or conventional postal service mail connection, perhaps
augmented by a hard- or softcopy catalog). Automated procedures can be
invoked via known endpoints (such as specific terminals or IP addresses), or
as ad hoc functionality (with or without prior arrangement with the
repository) over public or private networking and data management protocols.
" 

*	New ones flagged with "Normal" level of difficulty 

*	16, 17, 18, 20, 21, 23, 84, 100, 117, 127, 133, 200 

*	SC#16 - further discussion of Information Property Description is
needed 
*	SC#16 - Steve mentions work in PDS on 100 digit ASCII numbers 
relevant for Transformational Information Properties 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20170225/e930e7a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 856 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20170225/e930e7a6/attachment.png>