Fwd: criteria for what goes into Kernel Information

-------- Weitergeleitete Nachricht --------
Betreff: criteria for what goes into Kernel Information
Datum: Thu, 17 Aug 2017 01:12:02 +0000
Von: Plale, Beth A.
<***@***.***>
An: TobiasWeigel <***@***.***>, ***@***.***-groups.org
<***@***.***-groups.org>
Kopie (CC): Plale, Beth A.
<***@***.***>
I'd like to advocate for a decision criteria for inclusion / disclusion
for kernel information be based on whether the information is structural
metadata. If a field is structural in nature, it qualifies for
inclusion. If not structural, it does not. I'd like to discuss this
tomorrow if agenda permits.
A definition of structural metadata that I think is most appropriate
comes out of the digital library community*: ____________________
In digital library community usage, structural metadata describes the
intellectual or physical elements of a digital object. For a file that
represents a single page as a compound document (e.g., a JPEG 2000 jpm
file), the structural metadata may include information on page layout.
In a multi-file digital object (e.g., a scanned book with many page
images), structural metadata describes the object's components and their
relationships: pages, chapters, tables of contents, index, etc. Such
metadata can support sophisticated search and retrieval actions as well
as the navigation and presentation of digital objects. METS offers one
model for the encoding of structural metadata.
In some engineering and related technical contexts, the term structural
metadata refers to physical or technical information about a digital
object, such as file format, size, media, etc. ______________________
What can be done with structural metadata alone? With structural
metadata alone one can:
-- linking related objects, -- verifying quality
-- making optimization decisions (based on size)
-- associating actionable entities to a data object (such as registering
a reader in DTR for a file format or media)
-- allows information about object granularity to
This I advocate is a strong set of functionality. Additionally,
structural metadata can be bounded far more easily than can trying to
draw a fuzzy line around and through descriptive metadata.
beth
* http://www.digitizationguidelines.gov/term.php?term=metadatastructural
________________________________________
From: weigel=***@***.***-groups.org <***@***.***-groups.org> on
behalf of TobiasWeigel <***@***.***>
Sent: Wednesday, August 16, 2017 12:00 PM
To: Ulrich Schwardmann; ***@***.***-groups.org
Cc: Plale, Beth A.
Subject: Re: [pid-kernel-info-wg] Notes from today's PID KernelInfo call
Hello Ulrich,
in view of tomorrow's call, I've gone through your notes again and came
up with a couple of detail questions (can ask tomorrow), but more
importantly, observations regarding future directions of the group:
a) We need a better and somewhat formal description of the crawling &
selection process, including the decision-making part
b) We need a framework for condition specifications. You've already put
some cornerstones in place (categories) and some essential requirements
(simple machine-readability, compatibility).
Also, I'm musing about how complete your various points are - e.g. the 3
decision crawling categories - I did not find gaps so far, which is
good, but it might still worth thinking about extensions. But the two
items above may be more direct regarding next steps.
Best, Tobias