Avalon MODS to RDF
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
Comment only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAA
1
Form field labelMODS elementRDF propertyNotes
2
Bibliographic IDrelatedItem@type="original"/identifierowl:sameAsused for importing descriptive info, see Bibliographic ID Label for mapping recommendations to migrate this info.
3
Bibliographic ID LabelrelatedItem@type="original"/identifier@typethis should be a URI since it is used to import the record and should translate to whatever URI is used for importing (OCLC, Z39.50 call, etc). If that's the case, then could use something like bf2:references or owl:sameAs to identify this as the identifier for importing the record. Choosing owl:sameAs since we definitely want to use URI value and bf2 wants to see a FRBR-based URI and that is not what this will be.
4
Other IdentifierrelatedItem@type="original"/identifierthis is what is mapped to RDF based on the label
5
Other Identifier LabelrelatedItem@type="original"/identifier@typelccn = loc:lccn; issue number = loc:issue-number; matrix number = loc:matrix-number; music publisher = loc:music-publisher; video recording identifier = loc:videorecording-identifier; oclc = dbpedia:oclc; other=loc:localDon't have mapping for identifier@type="other" (maybe loc:local if different mapping can be used for bib import id?) See link at end of this column for Avalon identifiers proposal. Use loc:local for @type="other."
6
TitletitleInfo/titledcterms:title
7
Creator
name@usage="primary"/namePart (role/roleTerm set to "Creator")
dc:creatorrequires URI for value - migration would need to resolve text names to URIs or create local URIs for names; helpful to have form with Questioning Authority-style autocomplete to work off of LCNAF. Changing from MODS/RDF mapping to dc:creator because too many names will not map - easier path forward to bring this in as text value.
8
Contributorname/namePart (role/roleTerm set to "Contributor")dc:contributorrequires URI for value - migration would need to resolve text names to URIs or create local URIs for names; helpful to have form with Questioning Authority-style autocomplete to work off of LCNAF. Changing from MODS/RDF mapping to dc:creator because too many names will not map - easier path forward to bring this in as text value.
9
Genregenreedm:hasType
10
PublisheroriginInfo/publisherdcterms:publisher
11
Date CreatedoriginInfo/dateCreated@encoding=”edtf”dcterms:created
12
Date IssuedoriginInfo/dateIssued@encoding=”edtf”dcterms:issued
13
Abstract
abstractdcterms:abstract
14
Languagelanguage/languageTermdcterms:languageMODS and RDF Subgroup mapping these to ISO639-2 but we're using MARC Language codes, so migration would end up with URI values like: http://id.loc.gov/vocabulary/languages/eng
15
Physical Description
relatedItem@type="original"/physicalDescription/extent
bibframe:extentMODS and RDF Subgroup mapping this to Bibframe 1.0 - need to use this since Bibframe 2.0 requires URI value for extent; could also use Bibframe Lite (Zepheira's Bibframe used with SirsiDynix) - http://bibfra.me/view/lite/extent/
16
Related Item URLrelatedItem@displayLabel/location/urlrdfs:seeAlsoMODS and RDF Subgroup doesn't have a mapping for this yet; the value will always be a URI so dcterms:relation works.
rdfs:seeAlso matches what Hyrax uses.
17
Related Item LabelrelatedItem@displayLabelrdfs:labelNot sure how to handle this - rdfs:label is probably not specific enough to identify a label for the related item URL; could use dc:relation for this text label and dcterms:relation holds the URI, dc should be able to take a literal and they are essentially the same thing (one is text version and the other the URI); problem if there is more than one related item (which dc:relation gose with which dcterms:relation?). Using rdfs:label with rdfs:seeAlso ties these pieces together so even though the namespace is a bit generic it can work in the Avalon/Hydra context.
18
Topical Subjectsubject/topicdc:subjectWould like to use dcterms:subject and require URIs but that would mean external reconciliation, which is probably not realistic. Sticking with text-based dc:subject to make migration easier.
19
Geographic Subjectsubject/geographicdcterms:spatialThis will require reconciling locations to have URIs available for the value. We ask for folks to use TGN so maybe we could reconcile and provide a report of records that don't work for migration?
20
Temporal Subjectsubject/temporalbf2:temporalCoveragebf2:temporalCoverage takes a literal value. We ask for EDTF timespans in this field but who knows what has actually gone in there. If it's being used for date indexing then we should try to use something that has dates as values, and I'm not sure what would work for that. Dates are a type of string so a literal like what is needed for bf2:temporalCoverage could work but we'd have to have our own checks that the values are dates if we need them to be dates.
21
Permalinklocation/url@access="object in context"dc:identifierMaps the permalink for the item which can be generated automatically by Avalon or manually entered. MODS and RDF group has homework but no collaboration document yet. URI doesn't exist unless the system is set up to create PURLs. Contemplating using this as the unique identifier for the item so possibly it is used with edm:isShownAt and dc:identifier? See link below for Avalon identifers proposal. Changing from edm:isShownAt to dc:identifier - provides a double use for single property - permalink and unique identifier. Also matches how Hyrax uses dc:identifier.
22
Terms of Use
accessCondition@type="use and reproduction"
dc:rightsIdeally, we'd offer to map these to a URI from Rightsstatement.org or CC during a migration but there is probably still a need to have any text also brought over. A separate field for a Rights URI would make these items more shareable to places like DPLA.
23
Table of ContentstableOfContentsdcterms:tableOfContents
24
Statement of Responsibility
note@type="statement of responsibility"skos:noteThis requires that we add in the label from the @type value, so the note comes across as "Statement of Responsibility: [note text]"
25
Note note skos:note
26
Note Typenote@typeskos:noteBasically if there is a @type then that value becomes a label added to the note text with a colon: "[@type value]: [note text]"
27
28
29
30
31
32
33
34
35
36

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
Main menu