-
Notifications
You must be signed in to change notification settings - Fork 6
Reactions and Open Discussion
betsypost edited this page Sep 29, 2014
·
14 revisions
METS … Now, and Then: Current and Future Data Models Notes from Panel Discussion (9/12/2014) recorded by Betsy Post:
Rob:
- Conceptually liked the METS 2.0 data model presentation; thoughts about how to get there?
- Want a data model for METS but also want to re-use parts of other models – but which bit is METS?
- How do you have a full data model when re-using parts of other models?
Nate:
- METS is a wrapper
Rob:
- It would be good if all schemas had a view of what they are trying to do and what they are not trying to do so we know how to use them together without confusion.
Antoine:
- Could have a data model with indications of what is re-used for serialization (e.g. note when we are delegating to PREMIS).
Markus:
- Consider
- (1) Creating subclasses of what PREMIS has done
- (2) OR, define for both schemas and use owl:sameas
- Advantage of using owl:sameas is that when the definitions change in a related schema you can just change the sameas
- owl:sameas approach is more resilient than subproperty or subclass
Rob:
- This approach is delegating responsibility, but not completely…
- …consequently making it harder to say (on a permanent basis); what we are not doing
Nate:
- So maybe we will need to negotiate changes (trivial changes?) with other standards for synchronization.
Jo:
- Statement about what schema does and does not do reminds him of METS Lite
- METS is easy to explain and transmit to clients.
- → Size of METS is a problem too big to parse in
Tobias: Thinking about what METS is and why to use it is an important question
- For him METS has always been a container of metadata. If this is useful, stress this.
- Core principle: capturing and encapsulating different kinds of metadata
Tom:
- The other core principle is documenting complex structure
Student:
- The closer METS gets to other standards; the less likely people will be to use it.
Karin:
- Consider XFDU [XML Formatted Data Unit (XFDU): CCSDS 661.0-R-1-- a spec from the folks at CCSDS who brought us OAIS] – a slight variation of METS -- accommodates data sets
Rob:
- Backward compatibility needs to be thought through
- If you are going to have a container (a strength)
- (1) Then need to think about where data is coming from – may be a data dump that is not in RDF
- (2) Define use cases
Tom:
- May get use cases from registered profiles; and use registered profiles as test cases for new model
- Other use cases: Docworks; Preservica example
Markus:
- Do people still see METS as a container?
- Now people are using METS to store data
- Markus has a use case which requires accessing different objects within the container
- (1) Difference between container and aggregation entity
- (2) Markus has the need to create different dissemination packages from a single METS object i.e. He wants to create different DIPS; not the whole container
Andreas:
- The ingest phase is when you need the monolithic container, as soon as it is in the repository you should be able to easily access different components within the container
Tobias:
- It is called METS [T is for Transmission]
- (1) BUT, is it more than a transmission standard
- (2) Is it a description of a data model you want to use in your own system?
Markus:
- Yes, he would like one vocabulary to streamline internal processes.
Rob:
- XIP – stored in fragments – single container; for AIP, XIP is inefficient because you have to use the whole container
Antoine:
- Not having a container will really hurt???
- Think of a new version that just focuses on the structMap
Jo:
- Tobias made a good point; what are the key uses of METS
-
- Internally you have different demands than transmission requires
Andreas:
- If we are looking closely at PREMIS, then we are using PREMIS for technical metadata
- Consider owl:same as instead of sub-classing
Rob:
- Some parts of PREMIS are basic so you wouldn’t use that part of PREMIS; eg. Premis:rights
Nate:
- If the METS schema is to be closely tied to PREMIS, then a more formal relationship between the schemas is needed.
Rob:
- There is a danger of being too closely aligned to PREMIS -> sometimes his company is forced to work with a national schema due to legal requirements.