Skip to content
This repository has been archived by the owner on Jun 26, 2020. It is now read-only.

Extensible models for object relationships tag/value pairs #73

Open
gregjan opened this issue Sep 29, 2011 · 0 comments
Open

Extensible models for object relationships tag/value pairs #73

gregjan opened this issue Sep 29, 2011 · 0 comments

Comments

@gregjan
Copy link
Contributor

gregjan commented Sep 29, 2011

So many repositories have their own content models and interrelated objects. Indeed, even within one repository you may have multiple, sometimes overlapping sets of object relationships, types, or attribute/value pairs. These are recorded and sometimes enforced in a variety of ways. As a tool that fits in between repositories or data structures, the workbench needs to allow this kind of annotation, without getting bogged down in any one particular model.

While METS does make room for certain attributes and structural relationships, these are limited to xlink form and XML ID references. We have mapped such smLinks for things like surrogate/thumbnail relationships. But RDF might offer some advantages and could just as easily be embedded in METS.

Object Types:

  • Div/@type - this can only express 1 concrete type, perhaps implying others (AFAIK)
  • RDF types can be multiple, like tags. They can also be formal rdfs classes.

Object Attributes:

  • Custom attributes in METS generally have to be placed in an embedded XML doc of some kind
  • RDF is a generic bucket for custom attributes, whether encoded in XML or N3, etc..

So if the workbench support RDF tagging of the arranged objects, you could pick and choose the namespaces you wanted to use. Some could be custom and others could be standard, such as LOC PREMIS RDF. They can be mixed together on the same objects. Seems ideal.

This issue is really a placeholder for a compelling design idea for the software. Comment freely!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant