[Moims-dai] Reminder of Skype call today

Tue Feb 4 10:09:39 UTC 2020

Meeting: 10:00 Tuesday (EST), 1500 UK time, 1600 Paris time

Join it by clicking the link:

https://join.skype.com/ykyu5SIPhSnD

*Don't have Skype yet? Download it before you join https://www.skype.com

General schedule:

Tuesday of the month

Activity

Technical Editor(s)

1st 

ISO 16363    Audit and Certification Metrics

John Garrett, David Giaretta

2nd

IPELTU Info Preservation Enabling Long-Term Usage

David Giaretta, Roberta Svanetti

3rd

OAIS-IF DAADD    OAIS Interoperability Framework – Digital Archive Architecture Design Doc

Steve Hughes

4th

OAIS update finalization, Group administration, Planning, new projects, or special issues identified other weeks

5th 

OAIS update finalization, Group administration, Planning, new projects, or special issues identified other weeks

Draft agenda this week (1st Tuesday of the month):

1.	We are using http://review.oais.info  to track actions – see http://review.oais.info/buglist.cgi?bug_status=__open__ <http://review.oais.info/buglist.cgi?bug_status=__open__&list_id=2522&order=Importance&product=ACTIONS&query_format=specific> &list_id=2522&order=Importance&product=ACTIONS&query_format=specific
2.	A reminder that we have received 26 RIDs for OAIS – what we have called “suggested changes” - from CCSDS-SEA: see http://review.oais.info/show_bug.cgi?id=281  to http://review.oais.info/show_bug.cgi?id=306 . Please put in your responses to these so we can discuss them in detail.

I suggest we try to get through a number of the following on OAIS, in case they affect ISO 16363.

We can probably relatively quickly do 283, 284, 285, 286, 287, 288, 302, 303, 304, 305 and 306 – highlighted below.

Ones that need further thought are: 290, 292, 298 and 299.

Bug ID

Summary

Changed

Explanation of the reason for the suggested change

283

SEA-650x0-003

21/01/2020 10:40

I think it is useful to be clear that these are abstractions and there is no expectation that they can be directly implemented.  This is stated, in different terms, in Sec 1.4.

Even with the specific use of abstract, but formal, language for these systems elements there can be no assumption that this is a specification for how to build a system.  At best it might become a specification for how to think about designing and building a system.  Or evaluating existing systems.

284

SEA-650x0-004

18/01/2020 19:09

The ASL is being contemporaneously processed and it covers the OAIS as well as the rest of MOIMS and SOIS.  Instead of using a separate, and non-standard, set of representations, which are in some cases hard to understand, I recommend that OAIS adopt the ASL/RASDS representations.  It will make understanding all of this much easier.  See attached screenshot of ASL Fig 3-1.

285

SEA-650x0-005

21/01/2020 10:56

The definitions of semantics and syntax, as stated, are weakly specified and somewhat intertwined.

286

SEA-650x0-006

18/01/2020 19:47

The term "metadata" is widely used and understood, but it only appears in a couple of places in this document(pg 4-15, 4-33).  The two separate thoughts embodied in the current "Representation information" description should probably be sorted out and clarified.  They are distinct.

287

SEA-650x0-007

18/01/2020 19:51

Re-think whether this paragraph really adds anything or if it misses the mark entirely.

288

SEA-650x0-008

21/01/2020 11:16

Is the ability to "re-perform an artistic piece", presumably with different musicians, actors, or dancers, really an instance of "digital preservation"?  No argument with the value of preserving images, movies, and/or recordings of such artistic endeavors, but is "re-performance" really an aspect of preservation?

289

SEA-650x0-009

20/01/2020 08:22

This section introduces the term Submission Information Schema, and states that it has a formal definition and is "normally" used in the SA, but it neither defines this SIS (even abstractly) nor makes further reference to it.  if this is a formal definition that is normally part of an SA it should be defined somewhere.  The same situation seems to obtain for "dissemination information schema" in the following sec 2.5.4.

290

SEA-650x0-010

19/01/2020 15:13

Consider if something further needs to be stated about "designated community" terminology in the basic sense and if it (the definitions of the semantics) needs to be archived along with the data itself.  This comes up again on pg 3-5 in sec 3.3.5.   But perhaps you think of this is another form of Representation Information?  If so, that should be clarified.

292

SEA-650x0-012

19/01/2020 21:26

Treating OS functions in the same way as OAIS services weakens their status.  Failing to provide even some abstract formalism for these important, exposed, OAIS service interfaces does likewise.  Note that this is not asking to define the internal service interfaces in a formal way, just the external ones exposed to the "users".

294

SEA-650x0-014

15/01/2020 19:50

In this section which addresses "Archive Interoperability" it would be ideal if a more formal set of definitions for registry, repository, query, and producer objects were used and if a set of clear, if abstract, interface definitions were provided.  The RASIM provides a clear set of abstract definitions for such functional objects as well as recipes for combining them to build information management systems. These could be put into an annex and referenced here.

The same situation occurs in re "repository" (see SEA-650x0-015).  It is also the case that none of the other documents in this series, OAIS (650.0), PAIS (651.0), nor TDR (652.0)provide any sort of concrete definitions for these fundamental building blocks for information management systems and their interfaces.  

Note that use of such abstract service interfaces is not the same as providing anything like a concrete interface spec or technology binding.  The treatment would still be abstract, and open to a separate transformation into interoperable designs, but it would be a whole lot clearer.

295

SEA-650x0-015

19/01/2020 21:45

In this section which addresses "Distributed Functionality" it would be ideal if a more formal set of definitions for registry, repository, query, and producer objects were used and if a set of clear if abstract, interface definitions were provided.  The RASIM provides a clear set of abstract definitions for such functional objects as well as recipes for combining them to build information management systems. 

The same situation occurs in re "registry" (see SEA-650x0-014).  It is also the case that none of the other documents in this series, OAIS (650.0), PAIS (651.0), nor TDR (652.0)provide any sort of concrete definitions for these fundamental, and essential, building blocks for information management systems and their interfaces.

296

SEA-650x0-016

20/01/2020 11:23

In this section which addresses OAIS Functional Entities would be vastly improved if a more formal set of definitions for registry, repository, query, and product service objects were used and if a set of clear if abstract, interface definitions were provided.  The RASIM provides a clear set of abstract definitions for such functional objects as well as recipes for combining them to build information management systems. 

Even though this is a Magenta Book, and as such describes entities in the abstract, these can be described in much clearer and more explanatory ways by referencing the RASIM abstract building block definitions and service interfaces.

297

SEA-650x0-017

15/01/2020 19:55

It feels as though a rather well known set of terms in knowledge management has been overlooked in favor of a locally defined term.  It is not clear that this is the best possible approach.

298

SEA-650x0-018

20/01/2020 12:03

This is just one of the types of registries that seem to be appropriate as "meta" functional objects in an Open Archive System.  A registry of package formats, for SIP, AIP, DIP, AIU, and PDI is another.  A registry of Finding, Ordering, and Retrieval Aids is another.

299

SEA-650x0-019

19/01/2020 21:52

This is just one of the types of data preservation that seems to be overlooked in this document.  Or maybe it is in here, as some aspect of "migration" and I just do not recognize it.

300

SEA-650x0-020

15/01/2020 20:00

An approach that covers the functional model, and information models, in Sec 6, and which is rather more comprehensive, even if it is still abstract and not directly implementable, would be a real improvement over what has been attempted so far.  This could start to provide a real interoperability framework for disparate archives.

301

SEA-650x0-021

15/01/2020 20:02

An approach like this, which is rather more challenging than what has been attempted so far, could start to provide a real interoperability framework for federated and distributed archives.

302

SEA-650x0-022

19/01/2020 22:11

These recommended changes will require some amount of work, but they will also make the document much more informative and useful.  As it is now it is more descriptive, using lots of words, than it is prescriptive.  The document could be moved in a more prescriptive direction while still dealing in abstractions and not directly implementable formalisms.

303

SEA-650x0-023

19/01/2020 22:17

I like the use of UML and the inclusion of this brief introduction in the document.  But I think that the addition of more specificity in these diagrams, such as adding at least operations, if not attributes, would make the descriptions even clearer.

304

SEA-650x0-024

15/01/2020 20:07

The idea of "conformance with requirements" given the extremely vague language in sec 2.3 and 3.2 seems disjoint with the usual CCSDS notions of conformance, even with regard to reference models.  There are materials in this document which could supply a much stronger framework for conformance, especially if the changes requested elsewhere in this set of RIDs are adopted.  Even in their absence, requiring conformance also with Sec 4 would provide a much stronger "compliance" test than just sec 2.3 and 3.2.

The weak nature of "conformance", as specified, is further called into suspicion when there is language like this in Sec 6.2.7, pg 6-12:

"It should be noted that in the example and elsewhere whenever something is named as an OAIS, it is expected that anything that is spoken about as an OAIS conforms to the full suite of OAIS criteria specified in the conformance subsection (1.4)."

That phrase "conforms to the full suite of OAIS criteria" sounds really strong, but in reality it is not.

305

SEA-650x0-025

16/01/2020 13:25

Coverage of security topics, for all archives in general, and for federated archives in particular, should be identified as required practices.  See also SEA-650x0-026.

306

SEA-650x0-026

16/01/2020 13:20

Coverage of security topics, for all archives in general, and for cooperating and federated archives in particular, should be identified as required practices.  See also SEA-650x0-025.

3.	OAIS-IF

a.	Steve circulated documents https://www.dropbox.com/s/x9g0we2yu56w1ik/02_White_Book_Recommended_Standard_OAIS-IF_Draft_191216%20v5.3%20NewSection3%20%281%29.doc?dl=0 , https://www.dropbox.com/s/x07qnsit8suhhq1/index_0300%20%282%29.html?dl=0 and diagram https://www.dropbox.com/s/8jcyrm50h4i59ks/Information_Model_Package_200102.jpg?dl=0 and spreadsheet of MicroServices at https://www.dropbox.com/s/gstbbh2vk3uq2un/MicroServices_191210_Generalized.xlsx?dl=0 
b.	I set up a shared Google doc for concept papers relevant to OAIS-IF, which have both had text and concepts added

                                                                           i.      A concept paper on Provenance – see https://docs.google.com/document/d/1YCyhBZKRP7IWhArdI3MnwahjZY5K93UsDZq-cWApYeI/edit?usp=sharing  

                                                                         ii.      A concept paper on Representation Information - https://docs.google.com/document/d/1TcYIDKc9WMdyK1POSuitQjdWc5VtlL-YG8Qkt8c8V18/edit?usp=sharing  

Regards

..David

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