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

 
View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAG
1
TimestampWhat is the scope of any "unofficial" standard from this group?
Do you care if you can regenerate semi-equivalent MODS XML from this RDF mapping?
Which mapping did you think held the most promise for the title element as a starting point?
Are you against the minting of local URIs at all costs?
Is there anything you particularly liked about the mapping models provided?
Is there anything you particularly disliked about the mapping models provided?
Other comments / feedback / ideas on how to handle this process or about the group in general?
2
8/14/2015 19:10:13A single complex MODS mapping to RDF that maintains all of MODS specificity on an element.YesNo
3
8/17/2015 14:19:02
Simplest common MODS mapping AND optional additional elements for more complex cases. (Allows for some minor specificity loss).
Yes
Would select myself so abstaining.
No
4
8/19/2015 14:08:20
Simplest common MODS mapping AND optional additional elements for more complex cases. (Allows for some minor specificity loss).
No
Would select myself so abstaining.
No
None of us dealt with @supplied very well (or at all). I'm not sure we're ready to give up this attribute, but we also don't know what to do with it while keeping our mapping simple.
It might be helpful to come up with a list of acceptance criteria for both simple and complex solutions for each element, so we can make expectations clear.
5
8/19/2015 19:40:24
Simplest common MODS mapping AND optional additional elements for more complex cases. (Allows for some minor specificity loss).
NoIndiana UniversityUnsure
I am uneasy with using both dcterms:title and skos:prefLabel for different values. I would think that dcterms:(or dc:)title, rdfs:label and skos:prefLabel should all be identical for an object.
I think mapping BACK to MODS is unnecessary. If you already have MODS prior to transform to RDF, Fedora allows you to save it as a bitstream. Maybe just do that if you feel you'll need MODS again.
6
8/19/2015 20:28:09not clear on the difference between the two AND scenarios, but one of thoseN/A or UnsureUnsure
On the second question, yes to some extent.

Difficult to answer number 3 because everyone started with such different scenarios, and because I think we should go with two versions of the mapping. For a complex mapping, I think BPL's was the most thorough and that people could scale that back if needed, so that would be a good place to start.

On the question about minting, I get the sense that it will probably be necessary for certain data.
7
8/20/2015 19:33:10
Simplest common MODS mapping AND optional additional elements for more complex cases. (Allows for some minor specificity loss).
Yes
Would select myself so abstaining.
No
Support for supplied, uniform, parallel, and translated titles in BPL models.
Lack of support for supplied, uniform, parallel, and translated titles in some models. Loss of specificity in most model examples.
It seems likely that we will need to propose strategies for metadata modeling that support both simple and complex use cases. Some institutions may have a lot of existing MODS metadata that they are unwilling to "round down" to a lower common denominator. However, some institutions simply don't need a high level of specificity when it comes to MODS subelements and attribute values.
8
8/23/2015 13:45:20
Simplest common MODS mapping AND optional additional elements for more complex cases. (Allows for some minor specificity loss).
N/A or Unsure
Would select myself so abstaining.
Unsure
I liked that we all seemed to agree on heading towards a simple RDF statement for title and, in general, using the same namespace (DC or DCTERMS). That makes me feel like we're all thinking about this the same way, which hopefully means we'll be able to agree on a common overall mapping for MODS to RDF.
I think our process and discussion are going well so far and we're working through issues that we need to figure out.
I like the idea of dealing with a "core" set of MODS elements that will need to be expressable in RDF for data functionality purposes (indexable data for search and browse and core data required for object identification). As a group, we need to spend some time to determine those if we go that route. Beyond that, I would consider other MODS elements to be those "optional additional elements for more complex cases" and I would also like us to consider a recommendation that the full static MODS XML be kept as a NonRDFResource on any object migrated from Fedora 3 to Fedora 4. If it's possible, I think it could also be worth it for us to share our findings and recommendations with the LOC group responsible for MODS in RDF - this might help them determine a more use-able way to express MODS as RDF or at least hear about the kinds of practical problems being encountered with their current transformation.
9
8/24/2015 13:42:32Simplest common MODS mapping AND a more complex mapping that maintains all of MODS specificity on an element.YesIndiana UniversityNo
I'm a little wary of relying entirely on dc:title, as many of the models did -- for a simplified version, sure, I think that we will run up against the limits of that very quickly.
I like the idea of providing a couple of options as guidelines. Not everyone is going to need to map to the same level of complexity, but at the same time, I think we want the output of this working group to be useful beyond the most basic level that can be expressed by Dublin Core.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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
Loading...
Main menu