Have you considered the LOCAH work in mapping EAD into Linked Data?

http://archiveshub.ac.uk/locah/
and
http://data.archiveshub.ac.uk/

Rob




On Sun, Jan 19, 2014 at 5:10 PM, Ben Companjen
<[log in to unmask]>wrote:

> Hi Eric,
>
> While I'm no archivist by training (information systems engineer I am),
> I've learned a thing or two from having to work with EAD and its basis for
> use, ISAD(G) (all citations below are from ISAD(G), 2nd edition). As with
> all information modelling, either inside or outside the Linked Data
> domain, you should take a step back to look at the goal of the
> description. When you have a list of what you want to describe, you can
> start looking for ontologies.
>
> You probably know this, but I was triggered by "Because many archival
> descriptions are rooted in MARC
>     records, and MODS is easily mapped from MARC." to respond. IMO
> archival descriptions are rooted in rules for description, not a specific
> file format.
>
> So, when I of (some of) the essences of archival description, I think of:
>
> - "The purpose of archival description is to identify and explain the
> context and content of archival material in order to promote its
> accessibility. This is achieved by creating accurate and appropriate
> representations and by organizing them in accordance with predetermined
> models." (§I.2)
> - "… seven areas of descriptive information:
>   1. Identity Statement Area
>      (where essential information is conveyed to identify the unit of
> description)
>   2. Context Area
>      (where information is conveyed about the origin and custody of the
> unit of description)
>   3. Content and Structure Area
>      (where information is conveyed about the subject matter and
> arrangement of the unit of description)
>   4. Condition of Access and Use Area
>      (where information is conveyed about the availability of the unit of
> description)
>   5. Allied Materials Area
>      (where information is conveyed about materials having an important
> relationship to the unit of description)
>   6. Note Area
>      (where specialized information and information that cannot be
> accommodated in any of the other areas may be conveyed).
>   7. Description Control Area
>      (where information is conveyed on how, when and by whom the archival
> description was prepared)." (§I.11)
>
>
>
> There is a distinction between the thing being described, and the
> description itself, and both have an important role within the archival
> description. (If anything so far causes confusion with anyone here, I
> misunderstood and accept to be corrected :))
> NB: this is one way of thinking of descriptions. Incorporating the
> PROV-ontology would make sense for expressing more/other aspects of the
> provenance of archival entities, but I haven't got round to becoming an
> expert of PROV yet ;)
>
>
> ISAD(G) lists 26 "elements that may be combined to constitute the
> description of an archival entity".
>
> Trying to translate these 'elements', I'd end up with possible a lot more
> than 26 RDFS/OWL properties.
> *Depending on the type of archival entity you can/should of course use
> more specific ontologies.*
>
>
>
> Let me list some properties and related ontologies.
>
>
>
>
>
> # Identity statement area
>
> ## Identifiers
> The URI, naturally, and other IDs. Could be linked using
> dc(terms):identifier, or mods:identifier, or other ontologies. Ideally
> there is some way of linking the domain of the ID to the ID itself,
> because "box 101" is likely not unique in the universe. Perhaps you want
> to publish a URI strategy separately to explain how the URI was
> assembled/derived.
>
> ## Title
> Again DC(terms), MODS, RDA
>
> ## Date(s)
> You want properties that have a clear meaning. For example,
> dcterms:created and mods:dateCreated assume it is clear what "when the
> resource was created" means. DC terms are vague, I mean general, on
> purpose. You could create some properties `owl:subPropertyOf` dcterms date
> properties for this.
> I'd look into EDTF for encoding uncertain dates and ranges and BCE dates
> (MODS doesn't support BCE dates).
>
> ## Level of description
> What kind of 'documentary unit' does the description describe? A whole
> building's content or one piece of paper? I don't know of any ontology
> with terms "fonds", …, "file", "item", but you could say `<http URI>
> rdf:type <fonds class URI>`.
>
> ## Extent and medium
> Saying anything about extent and medium should possible only happen on the
> lowest level of description. Any higher level extent and medium should be
> calculated by aggregating lower level descriptions.
> On the lowest level, refer to class URIs. A combination of dimensions and
> material {c|sh}ould be a class, e.g. A4 paper 80 grams/square meter.
>
> # Context area
>
> ## Creator(s) and administrative/biographical history
> As ISAD(G) refers to ISAAR(CPF) for description of corporate bodies,
> people, and families, this is a perfect example of using existing people-
> and organisation-describing ontologies like FOAF, BIO, ORG, and others are
> useful for separate descriptions of the people and organisations involved.
> You want specific properties to describe the roles of these 'agents' in
> the history of the archival entity…
>
> ## Archival history and Immediate source of acquisition or transfer
> … and you would want them 'here' (of course there is no particular order
> in which these properties are used). PREMIS and PROV come to mind first
> for recording who did what to what, (where and?) when and with what
> result. There are probably some ontologies describing possible "events" as
> RDFS/OWL classes, so you could link to those.
> The immediate source of acquisition or transfer may be just another event.
>
> # Content and structure area
>
> ## Scope and content
> Descriptions, keywords, terms from authority files about "scope (such as,
> time periods, geography) and content, (such as documentary forms, subject
> matter, administrative processes) … appropriate to the level of
> description.": pretty natural fit for links to SKOS thesauri and other
> ontologies of real-world 'things'.
> One might think of dcterms:subject, dcterms:description,
> dcterms:temporalCoverage etc., but describing *how* exactly such terms
> relate to the archival entity needs more specific properties than
> "subject" et al.
>
> ## Appraisal, destruction and scheduling information
> Reasons for including things and (possibly) removal of archival entities
> should go very well in rules, and some types of rules go very well in
> ontologies. Making this up as I type: <class of letters written by the
> head of state> rdfs:subClassOf <class of 'things to be kept'>. The actual
> selection and destruction actions could be modelled in the same way as
> other actions are described for provenance.
>
> ## Accruals
> Whether more content can be expected probably depends on other properties
> of the archival entity, like its type(s) and creator(s). I don't know
> about specific properties to record this, but <class of living heads of
> state archival entities> rdfs:subClassOf <class of 'living' archival
> entities>? There are ways of modelling rules for this, like the Rules
> Interchange Format, but the rules may be defined by the archives and
> archivists.
>
> ## System of arrangement
> Thinking about this, I tend to think of a collection of keywords to
> describe the arrangement of a low-level archival entity like a folder or
> box: alphabetical, as found on deceased's desk. But there is more, of
> course. Perhaps using the Collection Ontology for low levels could help
> generate higher level 'systems of arrangement'.
>
> # Conditions of access and use area
>
> ## Conditions governing access and Conditions governing reproduction
> You can describe rights with the Creative Commons Rights Expression
> Language.
>
> ## Language of material
> mods:language maybe? Preferably used on sub-document level and generated
> for higher-level descriptions.
>
> ## Physical characteristics / technical requirements
> Conditions should follow from their respective properties: <class of
> PDF/A-1b files> ..:requiresForReading <class of PDF/A-1b readers> and
> rules that say documents in <class A> are embargoed for 20 years after
> creation + a creation date can present enough information to the agent to
> determine dcterms:dateAvailable.
>
>
> ## Finding aids
> As a non-archivist I had some trouble understanding the difference between
> descriptions and finding aids and what the exact use of a finding aid was.
> Also, having grown up with search engines, indexes, I think the concept
> may eventually become extinct. I guess you could use foaf:page to link a
> document-like finding aid to the archival entity and rdfs:seeAlso to point
> to machine-actionable related things.
>
> # Allied materials area
>
> ## Existence and location of originals/copies
> PROV can be used to link a copy to an original (and how the copy was
> created etc.). `<X> prov:wasDerivedFrom <Y>. <Y> :isAt <AnotherArchive>.`
>
> ## Related units of description / Publication note
> Use properties that describe the specific relations among archival
> entities. DC Terms has some useful ones, like for citations. Related items
> can be derived from all or selected properties automatically too.
>
> # Notes area
> ## Notes
> dcterms:description? Unlike a document containing rules that needs to be
> finished at some time, Linked Data has no such rule. You can always create
> a property with a well-defined meaning to use for specific information.
>
> # Description control area
>
> ## Archivist's note / dates of description
> Who did what when, where, why and how to the description itself. Same as
> for the unit of description itself.
> This may be a good time to draw a bit more attention to the question:
> *what is a description?*
> I don't have a (/ there is no) final answer, but as The One True Written
> Paper Description from long ago is becoming a set of triples, you want to
> think about it. You could link versions of RDF documents using PROV to
> record this information.
>
> ## Rules and conventions
> A link to the rules and conventions for description. Could also fit with
> the PROV provenance.
>
>
>
> No, this is not a list of ontologies to use/explore right away, but I hope
> you (and others) find it helpful, or perhaps even food for discussion.
> Also, have a look at CIDOC-CRM. It has lots of properties.
>
> Regards,
>
> Ben
>
> On 19-01-14 03:39, "Eric Lease Morgan" <[log in to unmask]> wrote:
>
> >If you were to select a set of RDF ontologies intended to be used in the
> >linked data of archival descriptions, then what ontologies would you
> >select?
> >
> >
> >  * Dublin Core Terms - This ontology is rather bibliographic in
> >    nature, and provides a decent framework for describing much of
> >    the content of archival descriptions.
> >
> >  * FOAF - Archival collections often originate from individual
> >    people. Such is the scope of FOAF, and FOAF is used by a number
> >    of other sets of linked data.
> >
> >  * MODS - Because many archival descriptions are rooted in MARC
> >    records, and MODS is easily mapped from MARC.
> >
> >  * Schema.org - This is an up-and-coming ontology heralded by the
> >    600-pound gorillas in the room -- Google, Microsoft, Yahoo, etc.
> >    While the ontology has not been put into practice for very long,
> >    it is growing and wide ranging.
> >
> >  * RDF - This ontology is necessary because linked data is
> >    manifested as... RDF
> >
> >  * RDFS - This ontology may be necessary because the archival
> >    community may be creating some of its own ontologies.
> >
> >  * OWL and SKOS - Both of these ontologies seem to be used to
> >    denote relationships between terms in other ontologies. In this
> >    way they are used to create classification schemes and thesauri.
> >    For example, they allow the implementor to denote "creator" in one
> >    ontology is the same as "author" in another ontology. Or they
> >    allow "country" in one ontology to be denoted as a parent
> >    geographic term for "city" in another ontology.
> >
> >While some or all of these ontologies may be useful for linked data of
> >archival descriptions, what might some other ontologies include?
> >(Remember, it is often "better" to select existing ontologies rather than
> >inventing, unless there is something distinctly unique about a particular
> >domain.) For example, how about an ontology denoting times? Or how about
> >one for places? FOAF is good for people, but what about organizations or
> >institutions?
> >
> >Inquiring minds would like to know.
> >
> >—
> >Eric Morgan
>