| A | B | C | D | E | F | G | H | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MODS Top Level Element | Group Mappings | Sub-Elements/properties defined | Status | Reviewer | Hydra WG Questions/Notes | Opaque predicates/objects needed | Ideas | Simple | Complex | Predicates - Summary | Hyrax Default | ||||||||||||||||||
2 | 11 | note | MODS note (two supported options likely) | noteType label [for value] | Draft; reviewed | Danny / BPL | Complex mints objects, simple does not - can use a text prefix. For minted objects, bf Note | Simple seems fine. Complex uses rdfs:label (as specified in LC BF2.0 Specifications paper: https://www.loc.gov/bibframe/docs/pdf/bf2-notes-june2016.pdf) instead of skos:prefLabel, which we've used in other places. OK? For both, I cleaned up namespaces and text in the examples. Question. Examples are limited to notes BPL supports. Do we need other MARC note types? We would also need examples. | Y | Y | skos:note (simple) bf:note (complex) | N/A | ||||||||||||||||||
3 | 14 | relatedItem | MODS relatedItem (collections & series) | Draft; reviewed | Eben / BPL | Series and Collections | opaque:memberOfArchivalSeries | schema example: https://schema.org/Periodical ISSN as an identifier? dc source? | Options voting document | Y | Y ("Advanced") | bibframe:seriesStatement (simple) bibframe:subseriesStatement (simple) dcterms:partOf (simple, complex) opaque:memberOfArchivalSeries (complex) pcdm:memberOf (simple, complex) opaque:isAdministrativeMemberOf (simple, complex) bibframe:hasSeries (complex) | N/A; PCDM? | |||||||||||||||||
4 | relatedItem (other use cases) | MODS relatedItem (other use cases) | Draft; reviewed | Eben / BPL | Other parent-child use cases such as articles within a parent journal | Y | Y | rdau:P60101 (simple, complex) schema:pageStart (simple, complex) schema: pageEnd (simple, complex) identifiers:ean (simple, complex) dcterms:hasVersion (simple, complex) ebucore:eventName (simple) rdau:P60249 (simple, complex) bibo:presentedAt (complex) | N/A | |||||||||||||||||||||
5 | 16 | location | MODS physicalLocation | shelfMark holdings: heldBy sublocation enumeration | Draft; reviewed | Eben / BPL | Mappings for <location><physicalLocation> only? For <location><url>, is this addressed in identifier mapping (schema:url)? Do all heldBy/holding institution mappings require minting objects (agents)? Is this an implementation constraint for adopters? Could we use marcrelators:Repository as an alternative mapping? | TODO: Try to find non-German predicate for shelfMark (Eben) | Y | ? | [clarify if sub-tabs are simple, complex?] | N/A | ||||||||||||||||||
6 | 17 | accessCondition | MODS accessCondition | use and reproduction [string/text statement] rights URI [rightstatements.org; CCL uris] rightsHolder [URI for name entry] restrictions on access [URI for reused local statements?] | Draft; reviewed | Simon O'Riordan | Y | ? | [clarify if sub-tabs are simple, complex?] dc:rights dcterms: rightsHolder edm:rights dctermss:accessRights | dc.rights edm.rights | ||||||||||||||||||||
7 | 1 | titleInfo | MODS title (two tabs) | simple: title alternative @language complex: title prefLabel label @language hasSourceStatus type | Draft; reviewed | Julie Hardesty | Should there be a main title label without language for complex SPARQL querying? No? Removed question, no update needed Do we need "DC:title" string label in the custom minted resolutions? If this means dce:title, it might be good to use the same property consistently for the actual objects and local objects to know for sure what is the title; minted object is not a resource, it is just title so label is better than title property; use rdfs:label for custom minted - review difference btw rdfs:label vs skos:prefLabel - 2017-06-12 meeting decided to use rdfs:label instead of skos:prefLabel unless multiple labels are needed, still unclear for title since there are times where multiple titles are supplied, but not all the time; updated based on 2017-07-10 notes Does Fedora4 get confused skosxl and DCE both exsting? dce: is part of Fedora4 namespaces by default, skosxl: is not - additional programming will decide what happens with those properties [From Julie] Do we still need the "Back to MODS XML" column? No, removed [From Julie] Do we really need opaque:supplied? This seems to be recreating XML instead of defining object; look at bibliotek-o spec; Updated to use ld4l:hasSourceStatus since bibliotek-o isn't a resolvable ontology yet [From Julie] hasModel not defined in any examples, is this referring to Fedora4's info:fedora/fedora-system:def/model# definitions? Need to ask Emory about this but might be typo; hasModel removed from examples [From Julie, final note] Reviewed notes from first 4 meetings where title element discussed - no mention of rdfs:label vs skos:prefLabel, using prefLabel to show full title to display but unnecessary to use skos:prefLabel for this in minted object, changed to rdfs:label; concern with reproducing original MODS XML from RDF at time (early stages of group); also applied Idea listed here (to the right) to take out opaque properties in Complex column B and use dce:title with skosxl:prefLabel | Instead of opaque:alternativeTitle and opaque:translatedTitle, handle all of these as dce:title on object with skosxl:prefLabel identifying the primary title, like in parallel titles example - keeps info but simplifies how things need to be handled - change applied | Y | Y | dcterms:title (simple, complex) dcterms:alternative (simple) dce:title (simple, complex) skosxl:prefLabel (complex) | dc.title | ||||||||||||||||||
8 | 2 | name | MODS name (two tabs) | simple: name exactMatch role[of name] type nameOrder complex: role[of name] affiliation name birthDate deathDate exactMatch foaf[type of name entry] type prefLabel nameOrder | Draft; under review | Julie Hardesty | Clarify use of affiliation; legalname - schema:affiliation expects a URI so example is correct using schema:legalName; don't need schema:legalName, can still use foaf:name, which is simpler Is using marcrelators:creator less interoperable than dc:creator? Is a subproperty of DCE:creator - Recommend using dce:creator and dce:contributor and use relator: for roles that are there but can't be specified by dce: Could we use DC:creator PLUS more granular marcrelator terms for types of creators? (e.g. composer) If different names are tied to object and one is creator and one is composer, then yes, otherwise no [From Julie] Do we still need ""Back to MODS XML"" column? - removed nameOrder syntax - Parantheses in Turtle does signify order but results in a complex RDF statement (https://www.w3.org/TeamSubmission/turtle/#sec-examples) with rdf:first and then rdf:rest listing out each item after that in sub-graphs. This is likely too complex to store and manage in Fedora. Another option would be to change URIs to comma-separated list as text (in quotes). | opaque:nameOrder | Simple is way too complex - if there's a LD entry for name in ontology (id.loc.gov, viaf), use that as value on object and don't create local object use only one ontology for Organization type of name (schema) opaque:nameOrder can't work, it would just be the same property multiple times on the object and still wouldn't know proper order; still necessary for things like scientific publications; use new predicate with delimited string value? | Y | Y | relator:art (simple, complex) relator:ltg (simple, complex) relator:spn (simple, complex) dce:creator (simple) relator:aut (simple, complex) relator:cre (simple, complex) dce:creator (simple) relator:pht (complex) opaque:nameOrder (complex) | dce:creator dce:contributor | |||||||||||||||||
9 | 3 | typeOfResource | MODS typeOfResource | none | Draft; reviewed | Julie Hardesty | [From Julie] Do we still need the "Back to MODS XML" column? remove it | Y | N | dcterms:type (simple) | dc:type? | |||||||||||||||||||
10 | 4 | genre | MODS genre | none | Draft; reviewed | Eben / BPL | Y | N | edm:hasType (simple) | dc:type? | ||||||||||||||||||||
11 | 5 | originInfo | MODS originInfo (three tabs) | place of publication publisher name edition frequency date created date issued/published date copyrighted date note | Draft; reviewed | Eben / BPL | Inferred dates require the addition of a note to indicate inferred status. Note structure will be based on simple or complex note mapping, depending on implementor preference. | Y | ? (confirm for dates) | loc:pup (simple) dcterms:publisher (simple) bf:editionStatement (simple) rdau:P60538 (simple) bf:provisionActivity (complex) rdau:P60538 (complex) dcterms:created (?) skos:note (?) dcterms:issued (?) dcterms:dateCopyrighted (?) dcterms:date (?) | ||||||||||||||||||||
12 | 6 | language | MODS language | none | Draft; reviewed | Eben / BPL | Y | N | dcterms:language (simple) | dce:language | ||||||||||||||||||||
13 | 7 | physicalDescription | MODS physicalDescription | format [mimetype] digital origin extent note [e.g. marks] | Draft; reviewed | Jennifer Liss | Comment about not supporting the extent "unit" attribute May need to request new predicate for digitalOrigin; extent | opaque:extent; opaque:digitalOrigin | Y | N | N/A | |||||||||||||||||||
14 | 8 | abstract | MODS abstract | none | Draft; reviewed | Jennifer Liss | Y | N | dce:description | |||||||||||||||||||||
15 | 9 | tableofContents | MODS tableOfContents | none | Draft; reviewed | Jennifer Liss | Comment: "Should this be a different property for web links like: http://bibframe.org/vocab/tableOfContents.html" | Y | N | N/A | ||||||||||||||||||||
16 | 10 | targetAudience | MODS targetAudience (only BPL and UNC-CH mapped this) | none | Draft; reviewed | Danny / BPL | Added class. Updated/completed custom example. Updated location of vocabulary. | Y | ? | N/A | ||||||||||||||||||||
17 | 12 | subject | MODS subject (spatial, topical) | prefLabel label [for value] exactMatch [uri] hasModel [for linking back to described object] spatial [for location context] | Draft; reviewed | Simon O'Riordan | Only has complex/minted option? Are we missing temporal mappings? | N | Y | dce:subject dce:relation/ schema:keywords? | ||||||||||||||||||||
18 | 13 | classification | MODS classification (only BPL and Columbia mapped this) | none | Draft; reviewed | Danny / BPL | CANDOC example not finished. I replaced it with an example for National Library of Medicine. But note that the example in our collab doc loses the distinction of the vocab (i.e., nlm). OK? Also, the domain of the 3 predicates are all different (dbo:Work, dbo:WrittenWork, dbo:Instrument). OK? | Y | N | N/A | ||||||||||||||||||||
19 | 15 | identifier | MODS identifier | none [type is inferred by predicate] | Draft; reviewed | Simon O'Riordan | opaque:accessionNumber; opaque:accessionNumberFormer; opaque:barcode | Y | N | dc:identifier | ||||||||||||||||||||
20 | 20 | recordInfo | MODS recordInfo | dataprovider provider recordOrigin descriptionLanguage descriptionConventions | Draft; reveiwed | Eben / BPL | document also includes tabs for part and extension but they note "not mapped"; seems like provider should be system-supplied, similar to recordCreationDate, recordChangeDate, etc.? (keep this, but maybe indicate system-supplied nature?) Also add in creation and change date -- use Fedora system predicates? | Y | ? | N/A? | ||||||||||||||||||||
21 | 21 | minted objects classes | Classes for minted objects | Draft | Eben / BPL | |||||||||||||||||||||||||
22 | 19 | extension | Not mapped due to too much variability | N/A | Not mapped | N/A | Confirmed that we aren't mapping this - too many variations to map collectively as a group. | |||||||||||||||||||||||
23 | 18 | part | Not mapped due to too much variability | N/A | Not mapped | N/A | Not mapped. Partially included in physicalDescription? | bibframe part - general purpose - literal | ||||||||||||||||||||||
24 | ||||||||||||||||||||||||||||||
25 | ||||||||||||||||||||||||||||||
26 | ||||||||||||||||||||||||||||||
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 |