rdf-vocab 3.1.5 → 3.1.10
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.md +10 -3
- data/VERSION +1 -1
- data/lib/rdf/vocab.rb +46 -20
- data/lib/rdf/vocab/acl.rb +20 -60
- data/lib/rdf/vocab/as.rb +90 -90
- data/lib/rdf/vocab/bf2.rb +552 -552
- data/lib/rdf/vocab/bibframe.rb +3456 -1706
- data/lib/rdf/vocab/bibo.rb +120 -123
- data/lib/rdf/vocab/cc.rb +18 -47
- data/lib/rdf/vocab/cert.rb +19 -126
- data/lib/rdf/vocab/cnt.rb +19 -19
- data/lib/rdf/vocab/crm.rb +240 -775
- data/lib/rdf/vocab/dbo.rb +1 -6
- data/lib/rdf/vocab/dc.rb +533 -99
- data/lib/rdf/vocab/dc11.rb +30 -30
- data/lib/rdf/vocab/dcat.rb +97 -96
- data/lib/rdf/vocab/dcmitype.rb +62 -12
- data/lib/rdf/vocab/disco.rb +58 -58
- data/lib/rdf/vocab/doap.rb +53 -55
- data/lib/rdf/vocab/dwc.rb +188 -188
- data/lib/rdf/vocab/earl.rb +27 -27
- data/lib/rdf/vocab/ebucore.rb +1231 -1521
- data/lib/rdf/vocab/edm.rb +52 -75
- data/lib/rdf/vocab/exif.rb +161 -162
- data/lib/rdf/vocab/extensions.rb +7 -3
- data/lib/rdf/vocab/fcrepo4.rb +21 -21
- data/lib/rdf/vocab/foaf.rb +75 -75
- data/lib/rdf/vocab/geo.rb +8 -109
- data/lib/rdf/vocab/geojson.rb +16 -16
- data/lib/rdf/vocab/geonames.rb +1342 -1350
- data/lib/rdf/vocab/gr.rb +177 -564
- data/lib/rdf/vocab/gs1.rb +958 -958
- data/lib/rdf/vocab/ht.rb +41 -41
- data/lib/rdf/vocab/hydra.rb +133 -85
- data/lib/rdf/vocab/iana.rb +71 -113
- data/lib/rdf/vocab/ical.rb +103 -151
- data/lib/rdf/vocab/identifiers.rb +161 -662
- data/lib/rdf/vocab/iiif.rb +25 -25
- data/lib/rdf/vocab/jsonld.rb +45 -53
- data/lib/rdf/vocab/ldp.rb +31 -31
- data/lib/rdf/vocab/lrmi.rb +170 -38
- data/lib/rdf/vocab/ma.rb +79 -79
- data/lib/rdf/vocab/mads.rb +9 -9
- data/lib/rdf/vocab/marcrelators.rb +4 -3
- data/lib/rdf/vocab/mo.rb +196 -539
- data/lib/rdf/vocab/mods.rb +121 -125
- data/lib/rdf/vocab/oa.rb +68 -72
- data/lib/rdf/vocab/og.rb +57 -35
- data/lib/rdf/vocab/ogc.rb +8 -8
- data/lib/rdf/vocab/ore.rb +13 -13
- data/lib/rdf/vocab/org.rb +46 -46
- data/lib/rdf/vocab/pcdm.rb +11 -33
- data/lib/rdf/vocab/pplan.rb +18 -196
- data/lib/rdf/vocab/premis.rb +315 -410
- data/lib/rdf/vocab/premiseventtype.rb +1 -1
- data/lib/rdf/vocab/prov.rb +87 -112
- data/lib/rdf/vocab/ptr.rb +34 -36
- data/lib/rdf/vocab/rdau.rb +10511 -0
- data/lib/rdf/vocab/rightsstatements.rb +12 -12
- data/lib/rdf/vocab/rsa.rb +8 -27
- data/lib/rdf/vocab/rss.rb +51 -10
- data/lib/rdf/vocab/schema.rb +5292 -4980
- data/lib/rdf/vocab/schemas.rb +26802 -0
- data/lib/rdf/vocab/sd.rb +38 -38
- data/lib/rdf/vocab/sh.rb +184 -184
- data/lib/rdf/vocab/sioc.rb +97 -97
- data/lib/rdf/vocab/siocservices.rb +8 -8
- data/lib/rdf/vocab/sioctypes.rb +38 -38
- data/lib/rdf/vocab/skos.rb +45 -47
- data/lib/rdf/vocab/skosxl.rb +12 -12
- data/lib/rdf/vocab/v.rb +32 -36
- data/lib/rdf/vocab/vcard.rb +117 -118
- data/lib/rdf/vocab/vmd.rb +32 -36
- data/lib/rdf/vocab/void.rb +26 -26
- data/lib/rdf/vocab/vs.rb +4 -4
- data/lib/rdf/vocab/wdrs.rb +22 -22
- data/lib/rdf/vocab/wot.rb +18 -18
- data/lib/rdf/vocab/xhv.rb +84 -200
- data/lib/rdf/vocab/xkos.rb +9 -9
- data/spec/spec_helper.rb +13 -0
- metadata +42 -14
data/lib/rdf/vocab/pcdm.rb
CHANGED
@@ -57,7 +57,7 @@ module RDF::Vocab
|
|
57
57
|
|
58
58
|
# Ontology definition
|
59
59
|
ontology :"http://pcdm.org/models#",
|
60
|
-
comment:
|
60
|
+
comment: "Ontology for the Portland Common Data Model, intended to underlie a wide array of repository and DAMS applications.".freeze,
|
61
61
|
"dc:modified": "2016/04/18".freeze,
|
62
62
|
"dc:publisher": "http://www.duraspace.org/".freeze,
|
63
63
|
"dc:title": "Portland Common Data Model".freeze,
|
@@ -67,43 +67,24 @@ module RDF::Vocab
|
|
67
67
|
|
68
68
|
# Class definitions
|
69
69
|
term :AlternateOrder,
|
70
|
-
comment:
|
71
|
-
An AlternateOrder is an alternate ordering of its parent's members. It should only order the
|
72
|
-
parent's members, and otherwise has all of the features of ordering \(some members may be
|
73
|
-
omitted from the order, members may appear more than once in the order, etc.\).
|
74
|
-
).freeze,
|
70
|
+
comment: "\n An AlternateOrder is an alternate ordering of its parent's members. It should only order the\n parent's members, and otherwise has all of the features of ordering (some members may be\n omitted from the order, members may appear more than once in the order, etc.).\n ".freeze,
|
75
71
|
isDefinedBy: "pcdm:".freeze,
|
76
72
|
label: "Alternate Order".freeze,
|
77
73
|
subClassOf: "pcdm:Object".freeze,
|
78
74
|
type: "rdfs:Class".freeze
|
79
75
|
term :Collection,
|
80
|
-
comment:
|
81
|
-
A Collection is a group of resources. Collections have descriptive metadata, access metadata,
|
82
|
-
and may links to works and/or collections. By default, member works and collections are an
|
83
|
-
unordered set, but can be ordered using the ORE Proxy class.
|
84
|
-
).freeze,
|
76
|
+
comment: "\n A Collection is a group of resources. Collections have descriptive metadata, access metadata,\n and may links to works and/or collections. By default, member works and collections are an\n unordered set, but can be ordered using the ORE Proxy class.\n ".freeze,
|
85
77
|
isDefinedBy: "pcdm:".freeze,
|
86
78
|
label: "Collection".freeze,
|
87
79
|
subClassOf: "ore:Aggregation".freeze,
|
88
80
|
type: "rdfs:Class".freeze
|
89
81
|
term :File,
|
90
|
-
comment:
|
91
|
-
A File is a sequence of binary data and is described by some accompanying metadata.
|
92
|
-
The metadata typically includes at least basic technical metadata \(size, content type,
|
93
|
-
modification date, etc.\), but can also include properties related to preservation,
|
94
|
-
digitization process, provenance, etc. Files MUST be contained by exactly one Object.
|
95
|
-
).freeze,
|
82
|
+
comment: "\n A File is a sequence of binary data and is described by some accompanying metadata.\n The metadata typically includes at least basic technical metadata (size, content type,\n modification date, etc.), but can also include properties related to preservation,\n digitization process, provenance, etc. Files MUST be contained by exactly one Object.\n ".freeze,
|
96
83
|
isDefinedBy: "pcdm:".freeze,
|
97
84
|
label: "File".freeze,
|
98
85
|
type: "rdfs:Class".freeze
|
99
86
|
term :Object,
|
100
|
-
comment:
|
101
|
-
An Object is an intellectual entity, sometimes called a "work", "digital object", etc.
|
102
|
-
Objects have descriptive metadata, access metadata, may contain files and other Objects as
|
103
|
-
member "components". Each level of a work is therefore represented by an Object instance,
|
104
|
-
and is capable of standing on its own, being linked to from Collections and other Objects.
|
105
|
-
Member Objects can be ordered using the ORE Proxy class.
|
106
|
-
).freeze,
|
87
|
+
comment: "\n An Object is an intellectual entity, sometimes called a \"work\", \"digital object\", etc.\n Objects have descriptive metadata, access metadata, may contain files and other Objects as\n member \"components\". Each level of a work is therefore represented by an Object instance,\n and is capable of standing on its own, being linked to from Collections and other Objects.\n Member Objects can be ordered using the ORE Proxy class.\n ".freeze,
|
107
88
|
isDefinedBy: "pcdm:".freeze,
|
108
89
|
label: "Object".freeze,
|
109
90
|
subClassOf: "ore:Aggregation".freeze,
|
@@ -111,7 +92,7 @@ module RDF::Vocab
|
|
111
92
|
|
112
93
|
# Property definitions
|
113
94
|
property :fileOf,
|
114
|
-
comment:
|
95
|
+
comment: "Links from a File to its containing Object.".freeze,
|
115
96
|
domain: "pcdm:File".freeze,
|
116
97
|
inverseOf: "pcdm:hasFile".freeze,
|
117
98
|
isDefinedBy: "pcdm:".freeze,
|
@@ -120,7 +101,7 @@ module RDF::Vocab
|
|
120
101
|
subPropertyOf: "ore:isAggregatedBy".freeze,
|
121
102
|
type: "rdf:Property".freeze
|
122
103
|
property :hasFile,
|
123
|
-
comment:
|
104
|
+
comment: "Links to a File contained by this Object.".freeze,
|
124
105
|
domain: "pcdm:Object".freeze,
|
125
106
|
isDefinedBy: "pcdm:".freeze,
|
126
107
|
label: "has file".freeze,
|
@@ -128,10 +109,7 @@ module RDF::Vocab
|
|
128
109
|
subPropertyOf: "ore:aggregates".freeze,
|
129
110
|
type: "rdf:Property".freeze
|
130
111
|
property :hasMember,
|
131
|
-
comment:
|
132
|
-
to component parts, such as a book linking to a page. Note on transitivity: hasMember is
|
133
|
-
not defined as transitive, but applications may treat it as transitive as local needs
|
134
|
-
dictate.).freeze,
|
112
|
+
comment: "Links to a subsidiary Object or Collection. Typically used to link\n to component parts, such as a book linking to a page. Note on transitivity: hasMember is\n not defined as transitive, but applications may treat it as transitive as local needs\n dictate.".freeze,
|
135
113
|
domain: "ore:Aggregation".freeze,
|
136
114
|
isDefinedBy: "pcdm:".freeze,
|
137
115
|
label: "has member".freeze,
|
@@ -139,7 +117,7 @@ module RDF::Vocab
|
|
139
117
|
subPropertyOf: "ore:aggregates".freeze,
|
140
118
|
type: "rdf:Property".freeze
|
141
119
|
property :hasRelatedObject,
|
142
|
-
comment:
|
120
|
+
comment: "Links to a related Object that is not a component part, such as an object representing a donor agreement or policies that govern the resource.".freeze,
|
143
121
|
domain: "ore:Aggregation".freeze,
|
144
122
|
isDefinedBy: "pcdm:".freeze,
|
145
123
|
label: "has related object".freeze,
|
@@ -147,7 +125,7 @@ module RDF::Vocab
|
|
147
125
|
subPropertyOf: "ore:aggregates".freeze,
|
148
126
|
type: "rdf:Property".freeze
|
149
127
|
property :memberOf,
|
150
|
-
comment:
|
128
|
+
comment: "Links from an Object or Collection to a containing Object or Collection.".freeze,
|
151
129
|
domain: "ore:Aggregation".freeze,
|
152
130
|
inverseOf: "pcdm:hasMember".freeze,
|
153
131
|
isDefinedBy: "pcdm:".freeze,
|
@@ -156,7 +134,7 @@ module RDF::Vocab
|
|
156
134
|
subPropertyOf: "ore:isAggregatedBy".freeze,
|
157
135
|
type: "rdf:Property".freeze
|
158
136
|
property :relatedObjectOf,
|
159
|
-
comment:
|
137
|
+
comment: "Links from an Object to a Object or Collection that it is related to.".freeze,
|
160
138
|
domain: "pcdm:Object".freeze,
|
161
139
|
inverseOf: "pcdm:hasRelatedObject".freeze,
|
162
140
|
isDefinedBy: "pcdm:".freeze,
|
data/lib/rdf/vocab/pplan.rb
CHANGED
@@ -6,208 +6,30 @@ module RDF::Vocab
|
|
6
6
|
# @!parse
|
7
7
|
# # Vocabulary for <http://purl.org/net/p-plan#>
|
8
8
|
# #
|
9
|
-
# # The P-Plan
|
9
|
+
# # The P-Plan Ontology
|
10
10
|
# #
|
11
|
-
# #
|
12
|
-
# #
|
13
|
-
# # PROV extension for linking Plans and parts of plans to their respective executions.
|
14
|
-
# # @version 1.3
|
11
|
+
# # The P-PLAN Ontology
|
15
12
|
# class PPLAN < RDF::StrictVocabulary
|
16
|
-
# # A p-plan:Activity represents the execution process planned in a p-plan:Step
|
17
|
-
# # @return [RDF::Vocabulary::Term]
|
18
|
-
# attr_reader :Activity
|
19
|
-
#
|
20
|
-
# # @return [RDF::Vocabulary::Term]
|
21
|
-
# attr_reader :Bundle
|
22
|
-
#
|
23
|
-
# # @return [RDF::Vocabulary::Term]
|
24
|
-
# attr_reader :Entity
|
25
|
-
#
|
26
|
-
# # @return [RDF::Vocabulary::Term]
|
27
|
-
# attr_reader :MultiStep
|
28
|
-
#
|
29
|
-
# # @return [RDF::Vocabulary::Term]
|
30
|
-
# attr_reader :Plan
|
31
|
-
#
|
32
|
-
# # @return [RDF::Vocabulary::Term]
|
33
|
-
# attr_reader :Step
|
34
|
-
#
|
35
|
-
# # @return [RDF::Vocabulary::Term]
|
36
|
-
# attr_reader :Variable
|
37
|
-
#
|
38
|
-
# # @return [RDF::Vocabulary::Term]
|
39
|
-
# attr_reader :correspondsToStep
|
40
|
-
#
|
41
|
-
# # @return [RDF::Vocabulary::Term]
|
42
|
-
# attr_reader :correspondsToVariable
|
43
|
-
#
|
44
|
-
# # @return [RDF::Vocabulary::Term]
|
45
|
-
# attr_reader :hasInputVar
|
46
|
-
#
|
47
|
-
# # @return [RDF::Vocabulary::Term]
|
48
|
-
# attr_reader :hasOutputVar
|
49
|
-
#
|
50
|
-
# # @return [RDF::Vocabulary::Term]
|
51
|
-
# attr_reader :isDecomposedAsPlan
|
52
|
-
#
|
53
|
-
# # @return [RDF::Vocabulary::Term]
|
54
|
-
# attr_reader :isInputVarOf
|
55
|
-
#
|
56
|
-
# # @return [RDF::Vocabulary::Term]
|
57
|
-
# attr_reader :isOutputVarOf
|
58
|
-
#
|
59
|
-
# # Property that asserts which Step preceeds the current one.
|
60
|
-
# # @return [RDF::Vocabulary::Term]
|
61
|
-
# attr_reader :isPrecededBy
|
62
|
-
#
|
63
|
-
# # @return [RDF::Vocabulary::Term]
|
64
|
-
# attr_reader :isStepOfPlan
|
65
|
-
#
|
66
|
-
# # @return [RDF::Vocabulary::Term]
|
67
|
-
# attr_reader :isSubPlanOfPlan
|
68
|
-
#
|
69
|
-
# # @return [RDF::Vocabulary::Term]
|
70
|
-
# attr_reader :isVariableOfPlan
|
71
|
-
#
|
72
13
|
# end
|
73
14
|
PPLAN = Class.new(RDF::StrictVocabulary("http://purl.org/net/p-plan#")) do
|
74
15
|
|
75
16
|
# Ontology definition
|
76
17
|
ontology :"http://purl.org/net/p-plan#",
|
77
|
-
|
78
|
-
"dc:
|
79
|
-
"dc:
|
80
|
-
"dc:
|
81
|
-
"dc:
|
82
|
-
"dc:
|
83
|
-
"
|
84
|
-
"http://
|
85
|
-
"
|
86
|
-
"
|
87
|
-
|
88
|
-
|
89
|
-
|
90
|
-
|
91
|
-
|
92
|
-
|
93
|
-
label: "Activity".freeze,
|
94
|
-
subClassOf: "prov:Activity".freeze,
|
95
|
-
type: "owl:Class".freeze
|
96
|
-
term :Bundle,
|
97
|
-
isDefinedBy: "pplan:".freeze,
|
98
|
-
label: "Bundle".freeze,
|
99
|
-
"prov:definition": "A p-plan:Bundle is a specific type of prov:Bundle that contains the provenance assertions of the execution of a p-plan:Plan".freeze,
|
100
|
-
subClassOf: ["pplan:Entity".freeze, "prov:Bundle".freeze],
|
101
|
-
type: "owl:Class".freeze
|
102
|
-
term :Entity,
|
103
|
-
isDefinedBy: "pplan:".freeze,
|
104
|
-
label: "Entity".freeze,
|
105
|
-
"prov:definition": "A p-plan:Entity represents the input of the execution of a p-plan:Activity. It corresponds to a p-plan:Variable.".freeze,
|
106
|
-
subClassOf: "prov:Entity".freeze,
|
107
|
-
type: "owl:Class".freeze
|
108
|
-
term :MultiStep,
|
109
|
-
isDefinedBy: "pplan:".freeze,
|
110
|
-
label: "MultiStep".freeze,
|
111
|
-
"prov:definition": "A multi step is the representation of a plan that appears as a step of another plan.".freeze,
|
112
|
-
subClassOf: ["pplan:Plan".freeze, "pplan:Step".freeze],
|
113
|
-
type: "owl:Class".freeze
|
114
|
-
term :Plan,
|
115
|
-
isDefinedBy: "pplan:".freeze,
|
116
|
-
label: "Plan".freeze,
|
117
|
-
"prov:definition": "A p-plan:Plan is a specific type of prov:Plan. It is composed of smaller steps that use and produce Variables.".freeze,
|
118
|
-
subClassOf: ["pplan:Entity".freeze, "prov:Plan".freeze],
|
119
|
-
type: "owl:Class".freeze
|
120
|
-
term :Step,
|
121
|
-
isDefinedBy: "pplan:".freeze,
|
122
|
-
label: "Step".freeze,
|
123
|
-
"prov:definition": "A p-plan:Step represents the planned execution activity".freeze,
|
124
|
-
type: "owl:Class".freeze
|
125
|
-
term :Variable,
|
126
|
-
isDefinedBy: "pplan:".freeze,
|
127
|
-
label: "Variable".freeze,
|
128
|
-
"prov:definition": "A p-plan:Variable represents a description of the input of the planned Activity (p-plan:Step)".freeze,
|
129
|
-
type: "owl:Class".freeze
|
130
|
-
|
131
|
-
# Property definitions
|
132
|
-
property :correspondsToStep,
|
133
|
-
domain: "pplan:Activity".freeze,
|
134
|
-
isDefinedBy: "pplan:".freeze,
|
135
|
-
label: "correspondsToStep".freeze,
|
136
|
-
"prov:definition": "p-plan:correspondsToStep links a p-plan:Activity to its planned p-plan:Step".freeze,
|
137
|
-
range: "pplan:Step".freeze,
|
138
|
-
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze]
|
139
|
-
property :correspondsToVariable,
|
140
|
-
domain: "pplan:Entity".freeze,
|
141
|
-
isDefinedBy: "pplan:".freeze,
|
142
|
-
label: "correspondsToVariable".freeze,
|
143
|
-
"prov:definition": "p-plan:correspondsToVariable binds a p-plan:Entity (used by a p-plan:Activity in the execution of a plan) to the p-plan:Variable it represented it in the p-plan:Plan.".freeze,
|
144
|
-
range: "pplan:Variable".freeze,
|
145
|
-
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze]
|
146
|
-
property :hasInputVar,
|
147
|
-
domain: "pplan:Step".freeze,
|
148
|
-
isDefinedBy: "pplan:".freeze,
|
149
|
-
label: "hasInputVar".freeze,
|
150
|
-
"prov:definition": "p-plan:hasInputVar binds a p-plan:Step to the p-plan:Variable that takes as input for the planned execution".freeze,
|
151
|
-
range: "pplan:Variable".freeze,
|
152
|
-
type: "owl:ObjectProperty".freeze
|
153
|
-
property :hasOutputVar,
|
154
|
-
domain: "pplan:Step".freeze,
|
155
|
-
inverseOf: "pplan:isOutputVarOf".freeze,
|
156
|
-
isDefinedBy: "pplan:".freeze,
|
157
|
-
label: "hasOutputVar".freeze,
|
158
|
-
"prov:definition": "p-plan:hasOutputVar binds a p-plan:Step to the p-plan:Variable that will be produced as output in the planned execution".freeze,
|
159
|
-
range: "pplan:Variable".freeze,
|
160
|
-
type: "owl:ObjectProperty".freeze
|
161
|
-
property :isDecomposedAsPlan,
|
162
|
-
domain: "pplan:MultiStep".freeze,
|
163
|
-
isDefinedBy: "pplan:".freeze,
|
164
|
-
label: "isDecomposedAsPlan".freeze,
|
165
|
-
"prov:definition": "The p-plan:isDecomposedAsPlan relationship binds a p-plan:MultiStep to the p-plan:Plan holding the definition of that step. That is, p-plan:isDecomposedAsPlan links the MultiStep to the Plan sptecification where it is decomposed.".freeze,
|
166
|
-
range: "pplan:Plan".freeze,
|
167
|
-
type: "owl:ObjectProperty".freeze
|
168
|
-
property :isInputVarOf,
|
169
|
-
domain: "pplan:Variable".freeze,
|
170
|
-
inverseOf: "pplan:hasInputVar".freeze,
|
171
|
-
isDefinedBy: "pplan:".freeze,
|
172
|
-
label: "isInputVarOf".freeze,
|
173
|
-
"prov:definition": "p-plan:isInputVarOf links an input variable of a step to the step.".freeze,
|
174
|
-
range: "pplan:Step".freeze,
|
175
|
-
type: "owl:ObjectProperty".freeze
|
176
|
-
property :isOutputVarOf,
|
177
|
-
domain: "pplan:Variable".freeze,
|
178
|
-
isDefinedBy: "pplan:".freeze,
|
179
|
-
label: "isOutputVarOf".freeze,
|
180
|
-
"prov:definition": "p-plan:isOutputVarOf is intended to link an output variable of a step to the step.".freeze,
|
181
|
-
range: "pplan:Step".freeze,
|
182
|
-
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze]
|
183
|
-
property :isPrecededBy,
|
184
|
-
comment: %(Property that asserts which Step preceeds the current one. ).freeze,
|
185
|
-
domain: "pplan:Step".freeze,
|
186
|
-
isDefinedBy: "pplan:".freeze,
|
187
|
-
label: "isPrecededBy".freeze,
|
188
|
-
range: "pplan:Step".freeze,
|
189
|
-
type: ["owl:ObjectProperty".freeze, "owl:TransitiveProperty".freeze]
|
190
|
-
property :isStepOfPlan,
|
191
|
-
domain: "pplan:Step".freeze,
|
192
|
-
isDefinedBy: "pplan:".freeze,
|
193
|
-
label: "isStepOfPlan".freeze,
|
194
|
-
"prov:definition": "p-plan:isStepOfPlan links a p-plan:Step to the p-plan:Plan which it corresponds to.".freeze,
|
195
|
-
range: "pplan:Plan".freeze,
|
196
|
-
type: "owl:ObjectProperty".freeze
|
197
|
-
property :isSubPlanOfPlan,
|
198
|
-
domain: "pplan:Plan".freeze,
|
199
|
-
isDefinedBy: "pplan:".freeze,
|
200
|
-
label: "isSubPlanOfPlan".freeze,
|
201
|
-
"prov:definition": "A p-plan:Plan may be a subplan of another bigger p-plan:Plan. p-plan:isSubPlanOfPlan is used to state the link among the two different plans. Note that if p1 is a p-plan:subPlan of p2, p1will not necessarily be a step of p2. A multistep will represent p1 in p2, and link to p1 with the p-plan.hasStepDecomposition relationship.".freeze,
|
202
|
-
range: "pplan:Plan".freeze,
|
203
|
-
subPropertyOf: "owl:topObjectProperty".freeze,
|
204
|
-
type: "owl:ObjectProperty".freeze
|
205
|
-
property :isVariableOfPlan,
|
206
|
-
domain: "pplan:Variable".freeze,
|
207
|
-
isDefinedBy: "pplan:".freeze,
|
208
|
-
label: "isVariableofPlan".freeze,
|
209
|
-
"prov:definition": "p-plan:IsVariableOfPlan binds a p-plan:Variable to the p-plan:Plan it corresponds to.".freeze,
|
210
|
-
range: "pplan:Plan".freeze,
|
211
|
-
type: "owl:ObjectProperty".freeze
|
18
|
+
"dc:created": "17 September 2013".freeze,
|
19
|
+
"dc:creator": ["http://delicias.dia.fi.upm.es/members/DGarijo/#me".freeze, "http://delicias.dia.fi.upm.es/members/DGarijo/#me".freeze, "http://www.isi.edu/~gil/".freeze],
|
20
|
+
"dc:isVersionOf": "http://purl.org/net/p-plan".freeze,
|
21
|
+
"dc:modified": "Release 12 March 2014".freeze,
|
22
|
+
"dc:rights": "https://creativecommons.org/licenses/by/4.0/".freeze,
|
23
|
+
"dc:title": ["The P-PLAN Ontology".freeze, "The P-Plan Ontology".freeze],
|
24
|
+
"prov:wasAttributedTo": ["http://delicias.dia.fi.upm.es/members/DGarijo/#me".freeze, "http://delicias.dia.fi.upm.es/members/DGarijo/#me".freeze, "http://www.isi.edu/~gil/".freeze],
|
25
|
+
"schema:author": ["http://delicias.dia.fi.upm.es/members/DGarijo/#me".freeze, "http://www.isi.edu/~gil/".freeze],
|
26
|
+
"schema:creator": "http://delicias.dia.fi.upm.es/members/DGarijo/#me".freeze,
|
27
|
+
"schema:dateCreated": "17 September 2013".freeze,
|
28
|
+
"schema:dateModified": "Release 12 March 2014".freeze,
|
29
|
+
"schema:mentions": ["http://www.w3.org/TR/prov-o/".freeze, "pplan:PROV-DM".freeze, "pplan:PROV-O".freeze],
|
30
|
+
"schema:name": ["The P-PLAN Ontology".freeze, "The P-Plan Ontology".freeze],
|
31
|
+
"schema:version": "1.3".freeze,
|
32
|
+
type: ["foaf:Document".freeze, "owl:Ontology".freeze, "schema:TechArticle".freeze, "schema:WebPage".freeze],
|
33
|
+
"xhv:license": "https://creativecommons.org/licenses/by/4.0/".freeze
|
212
34
|
end
|
213
35
|
end
|
data/lib/rdf/vocab/premis.rb
CHANGED
@@ -12,15 +12,15 @@ module RDF::Vocab
|
|
12
12
|
# # @version 1.0.0
|
13
13
|
# # @see http://multimedialab.elis.ugent.be/users/samcoppe/ontologies/Premis/index.html for the OWL Documentation of the ontology.
|
14
14
|
# class PREMIS < RDF::StrictVocabulary
|
15
|
-
# # The Agent entity aggregates information about attributes or characteristics of agents (persons, organizations, or software) associated with rights management and preservation events in the life of a data object. Agent information serves to identify an agent unambiguously from all other Agent entities.
|
16
|
-
# #
|
17
15
|
# # Entity properties: May hold or grant one or more rights. May carry out, authorize, or compel one or more events. May create or act upon one or more objects through an event or with respect to a rights statement.
|
16
|
+
# #
|
17
|
+
# # The Agent entity aggregates information about attributes or characteristics of agents (persons, organizations, or software) associated with rights management and preservation events in the life of a data object. Agent information serves to identify an agent unambiguously from all other Agent entities.
|
18
18
|
# # @return [RDF::Vocabulary::Term]
|
19
19
|
# attr_reader :Agent
|
20
20
|
#
|
21
|
-
# # Rationale Specific dates may apply to the particular rights statement.
|
22
|
-
# #
|
23
21
|
# # Definition: The date range during which the particular rights statement applies or is applied to the content.
|
22
|
+
# #
|
23
|
+
# # Rationale Specific dates may apply to the particular rights statement.
|
24
24
|
# # @return [RDF::Vocabulary::Term]
|
25
25
|
# attr_reader :ApplicableDates
|
26
26
|
#
|
@@ -36,37 +36,37 @@ module RDF::Vocab
|
|
36
36
|
# # @return [RDF::Vocabulary::Term]
|
37
37
|
# attr_reader :ContentLocation
|
38
38
|
#
|
39
|
-
# # Definition: Information about the copyright status of the object(s).
|
40
|
-
# #
|
41
39
|
# # Usage Notes: When rights basis is a copyright, copyrightInformation should be provided. Repositories may need to extend this with more detailed information. See the California Digital Library's copyrightMD schema (www.cdlib.org/inside/projects/rights/schema/) for an example of a more detailed scheme.
|
40
|
+
# #
|
41
|
+
# # Definition: Information about the copyright status of the object(s).
|
42
42
|
# # @return [RDF::Vocabulary::Term]
|
43
43
|
# attr_reader :CopyrightInformation
|
44
44
|
#
|
45
|
-
# # Creation / Maintenance Notes: If the object was created by the repository, assignment of creating application information should be straightforward. If the object was created outside the repository, it is possible this information could be supplied by the depositor. It might also be extracted from the file itself; the name of the creating application is often embedded within the file.
|
46
|
-
# #
|
47
45
|
# # Definition: Information about the application that created the object.
|
48
46
|
# #
|
49
47
|
# # Rationale: Information about the creating application, including the version of the application and the date the file was created, can be useful for problem solving purposes. For example, it is not uncommon for certain versions of software to be known for causing conversion errors or introducing artifacts. It is also useful to determine which rendering software is available for the digital object. For example, if you know that the Distiller program created the PDF file, you know it will be renderable with (among other programs) Adobe Reader.
|
50
48
|
# #
|
49
|
+
# # Creation / Maintenance Notes: If the object was created by the repository, assignment of creating application information should be straightforward. If the object was created outside the repository, it is possible this information could be supplied by the depositor. It might also be extracted from the file itself; the name of the creating application is often embedded within the file.
|
50
|
+
# #
|
51
51
|
# # Usage Notes: This semantic unit applies to both objects created external to the repository and subsequently ingested, and to objects created by the repository, for example, through migration events. The creatingApplication container is repeatable if more than one application processed the object in turn. For example, a file could be created by Microsoft Word and later turned into a PDF using Adobe Acrobat. Details of both the Word and Acrobat applications may be recorded. However, if both files are stored in the repository, each file should be completely described as an Object entity and linked by using relationship information with a relationshipType “derivation.” It may also be repeated to record the creating application before the object was ingested as well as the creating application used as part of the ingest process. For example, an HTML file was created pre-ingest using Dreamweaver, and the Web crawler Heritrix then captured a snapshot of the files as part of the ingest. The amount of information needed for creatingApplication given here is minimal. For more granularity, extensibility is provided. Rather than having each repository record this locally, it would be preferable to have a registry of this information similar to format or environment registries.
|
52
52
|
# # @return [RDF::Vocabulary::Term]
|
53
53
|
# attr_reader :CreatingApplication
|
54
54
|
#
|
55
|
-
# #
|
55
|
+
# # Definition: Information about a non-software component or associated file needed in order to use or render the representation or file, for example, a schema, a DTD, or an entity file declaration.
|
56
56
|
# #
|
57
57
|
# # Creation / Maintenance Notes: Recommended practice is for a repository to archive objects on which other objects depend. These may be sent by the submitter of the primary object, or they may in some cases be automatically obtained by the repository. For example, a markup file will often contain links to other objects it requires such as DTDs or XML Schema. If it does, these objects can often be identified by the link and downloaded by the repository.
|
58
58
|
# #
|
59
|
-
# #
|
59
|
+
# # Usage Notes: This semantic unit is for additional objects that are necessary to render a file or representation, not for required software or hardware. It may also be used for a non-executable component of the object, such as a font or style sheet. For things that the software requires, see swDependency. This semantic unit does not include objects required by structural relationships, such as child content objects (e.g., figures that are part of an article), which are recorded under relationship with a relationshipType of “structural”. It is up to the repository to determine what constitutes a dependency in the context of the designated community. The objects noted may be internal or external to the preservation repository.
|
60
60
|
# # @return [RDF::Vocabulary::Term]
|
61
61
|
# attr_reader :Dependency
|
62
62
|
#
|
63
|
-
# # Usage Notes: All of this semantic units’ subunits are optional. At least one subunit (i.e. environmentNote, dependency, software, hardware, and/or environmentExtension) must be present if this container is included.
|
64
|
-
# #
|
65
63
|
# # Creation / Maintenance Notes: This information may be omitted when the repository is doing only bit-level preservation on the object. Rather than having each repository record this locally, it would be preferable to have a registry of environment information similar to proposed registries of format information. Repositories may choose to design mechanisms for inheritance, so that if the environment required for each file within a representation is identical to the environment recorded for the representation as a whole, it is not necessary to store this information in each file.
|
66
64
|
# #
|
67
|
-
# #
|
65
|
+
# # Usage Notes: All of this semantic units’ subunits are optional. At least one subunit (i.e. environmentNote, dependency, software, hardware, and/or environmentExtension) must be present if this container is included.
|
68
66
|
# #
|
69
67
|
# # Rationale: Environment is the means by which the user renders and interacts with content. Separation of digital content from its environmental context can result in the content becoming unusable.
|
68
|
+
# #
|
69
|
+
# # Definition: Hardware/software combinations supporting use of the object.
|
70
70
|
# # @return [RDF::Vocabulary::Term]
|
71
71
|
# attr_reader :Environment
|
72
72
|
#
|
@@ -76,11 +76,11 @@ module RDF::Vocab
|
|
76
76
|
# # @return [RDF::Vocabulary::Term]
|
77
77
|
# attr_reader :Event
|
78
78
|
#
|
79
|
+
# # Definition: A detailed description of the result or product of the event.
|
80
|
+
# #
|
79
81
|
# # Usage Notes: This may be used to record all error and warning messages issued by a program involved in the event or to record a pointer to an error log. If the event was a validity check (e.g., profile conformance) any anomalies or quirks discovered would be recorded here. All subunits of this semantic unit are optional. At least one subunit (i.e. eventOutcomeDetailNote and/or eventOutcomeDetailExtension) must be present if this container is included.
|
80
82
|
# #
|
81
83
|
# # Rationale: An event outcome may be sufficiently complex that a coded description is not adequate to document it.
|
82
|
-
# #
|
83
|
-
# # Definition: A detailed description of the result or product of the event.
|
84
84
|
# # @return [RDF::Vocabulary::Term]
|
85
85
|
# attr_reader :EventOutcomeDetail
|
86
86
|
#
|
@@ -102,13 +102,13 @@ module RDF::Vocab
|
|
102
102
|
# # @return [RDF::Vocabulary::Term]
|
103
103
|
# attr_reader :Fixity
|
104
104
|
#
|
105
|
-
# #
|
106
|
-
# #
|
107
|
-
# # Definition: Identification of the format of a file or bitstream where format is the organization of digital information according to preset specifications.
|
105
|
+
# # Rationale: Many preservation activities depend on detailed knowledge about the format of the digital object. An accurate identification of format is essential. The identification provided, whether by name or pointer into a format registry, should be sufficient to associate the object with more detailed format information.
|
108
106
|
# #
|
109
107
|
# # Creation / Maintenance Notes: The format of a file or bitstream should be ascertained by the repository on ingest. Even if this information is provided by the submitter, directly in metadata or indirectly via the file name extension, recommended practice is to independently identify the format by parsing the file when possible. If the format cannot be identified at the time of ingest, it is valid to record that it is unknown, but the repository should subsequently make an effort to identify the format, even if manual intervention is required.
|
110
108
|
# #
|
111
|
-
# #
|
109
|
+
# # Definition: Identification of the format of a file or bitstream where format is the organization of digital information according to preset specifications.
|
110
|
+
# #
|
111
|
+
# # Usage Notes: A bitstream embedded within a file may have different characteristics than the larger file. For example, a bitstream in LaTex format could be embedded within an SGML file, or multiple images using different colorspaces could be embedded within a TIFF file. format must be recorded for every object. When the bitstream format can be recognized by the repository and the repository might want to treat the bitstream differently from the embedding file for preservation purposes, format can be recorded for embedded bitstreams. Although this semantic unit is mandatory, both of its subunits are optional. At least one subunit (i.e. either formatDesignation or formatRegistry) must be present if this container is included or both may be used. If the subunit (formatDesignation or formatRegistry) needs to be repeated, the entire format container is repeated. This allows for association of format designation with a particular set of format registry information. For example, if the precise format cannot be determined and two format designations are recorded, each is given within a separate format container. The format container may also be repeated for multiple format registry entries.
|
112
112
|
# # @return [RDF::Vocabulary::Term]
|
113
113
|
# attr_reader :Format
|
114
114
|
#
|
@@ -118,17 +118,17 @@ module RDF::Vocab
|
|
118
118
|
# # @return [RDF::Vocabulary::Term]
|
119
119
|
# attr_reader :FormatDesignation
|
120
120
|
#
|
121
|
+
# # Usage Notes: Either formatDesignation or at least one instance of formatRegistry is required. If more than one formatRegistry needs to be recorded the format container should be repeated to include each additional set of formatRegistry information. The PREMIS working group assumed that a number of format registries will be developed and maintained to support digital preservation efforts. The proposal for a Global Digital Format Registry (GDFR) (http://hul.harvard.edu/gdfr/documents.html#data), for example, would create a network-accessible registry designed to store detailed specifications on formats and profiles.
|
122
|
+
# #
|
121
123
|
# # Definition: Identifies and/or gives further information about the format by reference to an entry in a format registry.
|
122
124
|
# #
|
123
125
|
# # Rationale: If central format registries are available to the preservation repository, they may provide an excellent way of referencing detailed format information.
|
124
|
-
# #
|
125
|
-
# # Usage Notes: Either formatDesignation or at least one instance of formatRegistry is required. If more than one formatRegistry needs to be recorded the format container should be repeated to include each additional set of formatRegistry information. The PREMIS working group assumed that a number of format registries will be developed and maintained to support digital preservation efforts. The proposal for a Global Digital Format Registry (GDFR) (http://hul.harvard.edu/gdfr/documents.html#data), for example, would create a network-accessible registry designed to store detailed specifications on formats and profiles.
|
126
126
|
# # @return [RDF::Vocabulary::Term]
|
127
127
|
# attr_reader :FormatRegistry
|
128
128
|
#
|
129
|
-
# # Creation / Maintenance Notes: Hardware environment information can be very difficult to provide. Many different hardware environments may apply; there are a huge number of combinations of maker and type of CPU, memory, video drivers, and so on. Although at least one hardware environment should be recorded, it is not necessary to record them all and each repository will have to make its own decisions about which hardware environments to record. Because of the difficulty recording this information comprehensively, it would be optimal if central registries of environment information existed. In many cases the environment of a file object is directly associated with the format, making registry lookup by format feasible. In the absence of a global mechanism, repositories may be forced to develop their own local “registries” relating format to hwEnvironment.
|
130
|
-
# #
|
131
129
|
# # Definition: Hardware components needed by the software referenced in swName or the human user of the referenced software.
|
130
|
+
# #
|
131
|
+
# # Creation / Maintenance Notes: Hardware environment information can be very difficult to provide. Many different hardware environments may apply; there are a huge number of combinations of maker and type of CPU, memory, video drivers, and so on. Although at least one hardware environment should be recorded, it is not necessary to record them all and each repository will have to make its own decisions about which hardware environments to record. Because of the difficulty recording this information comprehensively, it would be optimal if central registries of environment information existed. In many cases the environment of a file object is directly associated with the format, making registry lookup by format feasible. In the absence of a global mechanism, repositories may be forced to develop their own local “registries” relating format to hwEnvironment.
|
132
132
|
# # @return [RDF::Vocabulary::Term]
|
133
133
|
# attr_reader :Hardware
|
134
134
|
#
|
@@ -136,41 +136,41 @@ module RDF::Vocab
|
|
136
136
|
# # @return [RDF::Vocabulary::Term]
|
137
137
|
# attr_reader :Identifier
|
138
138
|
#
|
139
|
-
# # Definition: Features of the object intended to inhibit access, use, or migration.
|
140
|
-
# #
|
141
139
|
# # Creation / Maintenance Notes: Inhibitors are more likely to be present on an object ingested by the repository than applied by the repository itself. It is often not possible to tell that a file has been encrypted by parsing it; the file may appear to be ASCII text. Therefore, information about inhibitors should be supplied as metadata with submitted objects when possible.
|
142
140
|
# #
|
143
|
-
# #
|
141
|
+
# # Definition: Features of the object intended to inhibit access, use, or migration.
|
144
142
|
# #
|
145
143
|
# # Rationale: Format information may indicate whether a file is encrypted, but the nature of the encryption also must be recorded, as well as the access key.
|
144
|
+
# #
|
145
|
+
# # Usage Notes: Some file formats allow encryption for embedded bitstreams. Some file formats such as PDF use passwords to control access to content or specific functions. Although this is actually implemented at the bitstream level, for preservation purposes it is effectively managed at the file level; that is, passwords would not be recorded for individually addressable bitstreams. For certain types of inhibitor keys, more granularity may be required. If the inhibitor key information is identical to key information in digital signatures, use those semantic units.
|
146
146
|
# # @return [RDF::Vocabulary::Term]
|
147
147
|
# attr_reader :Inhibitors
|
148
148
|
#
|
149
|
-
# # Definition: a set of content that is considered a single intellectual unit for purposes of management and description: for example, a particular book, map, photograph, or database. An Intellectual Entity can include other Intellectual Entities; for example, a Web site can include a Web page; a Web page can include an image. An Intellectual Entity may have one or more digital representations.
|
150
|
-
# #
|
151
149
|
# # Intellectual entities are described via Descriptive metadata models. These are very domain-specific and are out of scope for PREMIS. Examples: Dublin Core, Mets, MARC
|
150
|
+
# #
|
151
|
+
# # Definition: a set of content that is considered a single intellectual unit for purposes of management and description: for example, a particular book, map, photograph, or database. An Intellectual Entity can include other Intellectual Entities; for example, a Web site can include a Web page; a Web page can include an image. An Intellectual Entity may have one or more digital representations.
|
152
152
|
# # @return [RDF::Vocabulary::Term]
|
153
153
|
# attr_reader :IntellectualEntity
|
154
154
|
#
|
155
|
-
# # Usage Note: When rights basis is a license, licenseInformation should be provided.
|
156
|
-
# #
|
157
155
|
# # Definition: Information about a license or other agreement granting permissions related to an object.
|
156
|
+
# #
|
157
|
+
# # Usage Note: When rights basis is a license, licenseInformation should be provided.
|
158
158
|
# # @return [RDF::Vocabulary::Term]
|
159
159
|
# attr_reader :LicenseInformation
|
160
160
|
#
|
161
|
-
# # The object class aggregates information about a digital object held by a preservation repository and describes those characteristics relevant to preservation management. The only mandatory property is objectIdentifier. The object class has three subclasses: Representation, File, and Bitstream.
|
162
|
-
# #
|
163
161
|
# # Entity types: Representation: A digital object instantiating or embodying an Intellectual Entity. A representation is the set of stored digital files and structural metadata needed to provide a complete and reasonable rendition of the Intellectual Entity. File: A named and ordered sequence of bytes that is known to an operating system. Bitstream: Contiguous or non-contiguous data within a file that has meaningful properties for preservation purposes.
|
164
162
|
# #
|
163
|
+
# # The object class aggregates information about a digital object held by a preservation repository and describes those characteristics relevant to preservation management. The only mandatory property is objectIdentifier. The object class has three subclasses: Representation, File, and Bitstream.
|
164
|
+
# #
|
165
165
|
# # Entity properties: Can be associated with one or more rights statements. Can participate in one or more events. Links between entities may be recorded from either direction and need not be bi-directional.
|
166
166
|
# # @return [RDF::Vocabulary::Term]
|
167
167
|
# attr_reader :Object
|
168
168
|
#
|
169
|
-
# #
|
169
|
+
# # Definition: Technical properties of a file or bitstream that are applicable to all or most formats.
|
170
170
|
# #
|
171
171
|
# # Rationale: There are some important technical properties that apply to objects of any format. Detailed definition of format-specific properties is outside the scope of this Data Dictionary, although such properties may be included within objectCharacteristicsExtension.
|
172
172
|
# #
|
173
|
-
# #
|
173
|
+
# # Usage Notes: The semantic units included in objectCharacteristics should be treated as a set of information that pertains to a single object at a single compositionLevel. Object characteristics may be repeated when an object was created by applying two or more encodings, such as compression and encryption. In this case each repetition of objectCharacteristics would have an incrementally higher compositionLevel. When encryption is applied, the objectCharacteristics block must include an inhibitors semantic unit. A bitstream embedded within a file may have different object characteristics than the file. Where these characteristics are relevant for preservation, they should be recorded. When a single file is equivalent to a representation, objectCharacteristics may be applied and thus associated with the representation. In these cases, the relationship between the file comprising the representation and other associated files may be expressed using relationshipSubType.
|
174
174
|
# # @return [RDF::Vocabulary::Term]
|
175
175
|
# attr_reader :ObjectCharacteristics
|
176
176
|
#
|
@@ -178,13 +178,13 @@ module RDF::Vocab
|
|
178
178
|
# # @return [RDF::Vocabulary::Term]
|
179
179
|
# attr_reader :PremisEntity
|
180
180
|
#
|
181
|
-
# # Definition: Information indicating the decision or policy on the set of preservation functions to be applied to an object and the context in which the decision or policy was made.
|
182
|
-
# #
|
183
181
|
# # Creation / Maintenance Notes: The preservation level may be assigned by the repository or requested by the depositor and submitted as metadata. The repository may also choose to record additional metadata indicating the context for the assignment of the preservation level.
|
184
182
|
# #
|
183
|
+
# # Rationale: Some preservation repositories will offer multiple preservation options depending on factors such as the value or uniqueness of the material, the “preservability” of the format, the amount the customer is willing to pay, etc. The context surrounding the choice of a particular preservation option for an object may also require further explanation.
|
184
|
+
# #
|
185
185
|
# # Usage Notes: If the repository offers only a single preservation level, this value does not need to be explicitly recorded within the repository. Application of a particular set of preservationLevel semantic units may only cover a single representation of an object: representations in other technical forms or serving other functions may have a different preservationLevel applied. The container may be repeated if a preservation level value needs to be recorded in additional contexts (see preservationLevelRole).
|
186
186
|
# #
|
187
|
-
# #
|
187
|
+
# # Definition: Information indicating the decision or policy on the set of preservation functions to be applied to an object and the context in which the decision or policy was made.
|
188
188
|
# # @return [RDF::Vocabulary::Term]
|
189
189
|
# attr_reader :PreservationLevel
|
190
190
|
#
|
@@ -206,29 +206,29 @@ module RDF::Vocab
|
|
206
206
|
# # @return [RDF::Vocabulary::Term]
|
207
207
|
# attr_reader :RightsGranted
|
208
208
|
#
|
209
|
-
# #
|
209
|
+
# # Extensions: In OWL one can define its own subclasses to the the RightsStatement class to denote OtherRightsInformation of the PREMIS data dictionary.
|
210
210
|
# #
|
211
211
|
# # Usage Notes: This semantic unit is optional because in some cases rights may be unknown. Institutions are encouraged to record rights information when possible. Either rightsStatement or rightsExtension must be present if the Rights entity is included. The rightsStatement should be repeated when the act(s) described has more than one basis, or when different acts have different bases.
|
212
212
|
# #
|
213
|
-
# #
|
213
|
+
# # Definition: Documentation of the repository's right to perform one or more acts.
|
214
214
|
# # @return [RDF::Vocabulary::Term]
|
215
215
|
# attr_reader :RightsStatement
|
216
216
|
#
|
217
|
-
# # Definition: Information needed to use a digital signature to authenticate the signer of an object and/or the information contained in the object.
|
218
|
-
# #
|
219
217
|
# # Usage Notes: Several of the semantic components of signatureInformation are taken from the W3C’s XML-Signature Syntax and Processing; see www.w3.org/TR/2002/REC-xmldsig-core-20020212/ for more information on the structure and application of these semantic units.
|
220
218
|
# #
|
219
|
+
# # Definition: Information needed to use a digital signature to authenticate the signer of an object and/or the information contained in the object.
|
220
|
+
# #
|
221
221
|
# # Rationale: A repository may have a policy of generating digital signatures for files on ingest, or may have a need to store and later validate incoming digital signatures.
|
222
222
|
# # @return [RDF::Vocabulary::Term]
|
223
223
|
# attr_reader :Signature
|
224
224
|
#
|
225
|
+
# # Creation / Maintenance Notes: Significant properties may pertain to all objects of a certain class; for example, the repository can decide that for all PDF files, only the content need be preserved. In other cases, for example, for media art, the significant properties may be unique to each individual object. Where values are unique, they must be supplied by the submitter or provided by the curatorial staff of the repository.
|
226
|
+
# #
|
225
227
|
# # Definition: Characteristics of a particular object subjectively determined to be important to maintain through preservation actions.
|
226
228
|
# #
|
227
229
|
# # Rationale: Objects that have the same technical properties may still differ as to the properties that should be preserved for future presentation or use.
|
228
230
|
# #
|
229
231
|
# # Usage Notes: All of this semantic unit’s subunits are optional. At least one of the significantPropertiesValue and significantPropertiesExtension subunits must be present if this container is included or both may be used. Significant properties may be objective technical characteristics subjectively considered important, or subjectively determined characteristics. For example, a PDF may contain links that are not considered important and JavaScript that is considered important. Or future migrations of a TIFF image may require optimization for line clarity or for color; the option chosen would depend upon a curatorial judgment of the significant properties of the image. Listing significant properties implies that the repository plans to preserve these properties across time and requires them to acceptably survive preservation action; for example, to be maintained during emulation or after format migration. It also implies that the repository would note when preservation action results in modification of significant properties. In practice, significant properties might be used as measures of preservation success, as part of quality checking the results of a preservation action or evaluating the efficacy of a preservation method. For example, if the listed significant properties are not maintained after application of a particular preservation method, it may indicate a failure of the process or that the method is not well suited to the type of material. More experience with digital preservation is needed to determine the best ways of representing significant properties in general, and of representing modification of significant properties. The semantic units included in the significantProperties container aim to provide a flexible structure for describing significant properties, allowing general types of aspects, facets or attributes of an object to be declared and to be paired with specific significant details about the object pertaining to that aspect, facet or attribute. For example, some repositories may define significant properties for objects related to facets of content, appearance, structure, behavior, and context. Examples of facet:detail pairs in this case could include: significantPropertiesType = “content” significantPropertiesValue = “all textual content and images” significantPropertiesType = “behavior” significantPropertiesValue = “editable” Other repositories may choose to describe significant properties at a more granular attribute level; for example: significantPropertiesType = “page count” significantPropertiesValue = “7” significantPropertiesType = “page width” significantPropertiesValue = “210 mm” Each facet:detail pair should be contained in a separate, repeated significantProperties container. Further work on determining and describing significant properties may yield more detailed schemes to facilitate general description. Representing modification of significant properties as a result of preservation action also requires further work. One possible way involves the use of Object and Event information: Object A has significant properties volume and timing, which are recorded as significantProperties of A. In migrated version B, the timing is modified, which is noted in the eventOutcome of the migration event. Only volume is listed as a significant property of B.
|
230
|
-
# #
|
231
|
-
# # Creation / Maintenance Notes: Significant properties may pertain to all objects of a certain class; for example, the repository can decide that for all PDF files, only the content need be preserved. In other cases, for example, for media art, the significant properties may be unique to each individual object. Where values are unique, they must be supplied by the submitter or provided by the curatorial staff of the repository.
|
232
232
|
# # @return [RDF::Vocabulary::Term]
|
233
233
|
# attr_reader :SignificantProperties
|
234
234
|
#
|
@@ -238,16 +238,16 @@ module RDF::Vocab
|
|
238
238
|
# # @return [RDF::Vocabulary::Term]
|
239
239
|
# attr_reader :Software
|
240
240
|
#
|
241
|
-
# # Usage Notes: When rights basis is a statute, statuteInformation should be provided.
|
242
|
-
# #
|
243
241
|
# # Definition: Information about the statute allowing use of the object.
|
242
|
+
# #
|
243
|
+
# # Usage Notes: When rights basis is a statute, statuteInformation should be provided.
|
244
244
|
# # @return [RDF::Vocabulary::Term]
|
245
245
|
# attr_reader :StatuteInformation
|
246
246
|
#
|
247
|
-
# # Rationale: It is necessary for a repository to associate the contentLocation with the storageMedium.
|
248
|
-
# #
|
249
247
|
# # Usage Notes: Normally there would be a single storage location and medium for an object, because an object in another location would be considered a different object. The storage composite should be repeated if there are two or more copies that are identical bit-wise and managed as a unit except for the medium on which they are stored. They must have a single objectIdentifier and be managed as a single object by the repository. Although this semantic unit is mandatory, both of its subunits are optional. At least one subunit (i.e. either contentLocation or storageMedium) must be present or both may be used.
|
250
248
|
# #
|
249
|
+
# # Rationale: It is necessary for a repository to associate the contentLocation with the storageMedium.
|
250
|
+
# #
|
251
251
|
# # Definition: Information about how and where a file is stored in the storage system.
|
252
252
|
# # @return [RDF::Vocabulary::Term]
|
253
253
|
# attr_reader :Storage
|
@@ -264,56 +264,56 @@ module RDF::Vocab
|
|
264
264
|
# # @return [RDF::Vocabulary::Term]
|
265
265
|
# attr_reader :TermOfRestriction
|
266
266
|
#
|
267
|
-
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
268
|
-
# #
|
269
267
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/actionsGranted
|
270
268
|
# #
|
269
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
270
|
+
# #
|
271
271
|
# # Definition: The action the preservation repository is allowed to take.
|
272
272
|
# # @return [RDF::Vocabulary::Term]
|
273
273
|
# attr_reader :hasAct
|
274
274
|
#
|
275
|
-
# # Rationale: Digital provenance requires often that relationships between agents and events are documented. The role of the associated agent may need to be documented. For this, a SKOS vocabulary can be used. The LOC will publish a vocabulary at http://id.loc.gov/, denoting the agent's role. These vocabulary will publish the concepts also as subproperties to the linkingAgent property, for denoting the role of the agent in the event or rightsstatement.
|
276
|
-
# #
|
277
275
|
# # Definition: link to the associated Agent.
|
276
|
+
# #
|
277
|
+
# # Rationale: Digital provenance requires often that relationships between agents and events are documented. The role of the associated agent may need to be documented. For this, a SKOS vocabulary can be used. The LOC will publish a vocabulary at http://id.loc.gov/, denoting the agent's role. These vocabulary will publish the concepts also as subproperties to the linkingAgent property, for denoting the role of the agent in the event or rightsstatement.
|
278
278
|
# # @return [RDF::Vocabulary::Term]
|
279
279
|
# attr_reader :hasAgent
|
280
280
|
#
|
281
|
+
# # Definition: A text string which could be used in addition to agentIdentifier to identify an agent.
|
282
|
+
# #
|
281
283
|
# # Rationale: This semantic unit provides a more reader-friendly version of the agent identified by the agentIdentifier.
|
282
284
|
# #
|
283
285
|
# # Usage Note: The value is not necessarily unique.
|
284
286
|
# #
|
285
|
-
# # Definition: A text string which could be used in addition to agentIdentifier to identify an agent.
|
286
|
-
# #
|
287
287
|
# # Examples: Erik Owens, Pc
|
288
288
|
# # @return [RDF::Vocabulary::Term]
|
289
289
|
# attr_reader :hasAgentName
|
290
290
|
#
|
291
|
-
# # Definition: Additional information about the agent.
|
292
|
-
# #
|
293
291
|
# # Rationale: Additional information may be needed to describe or disambiguate the agent.
|
292
|
+
# #
|
293
|
+
# # Definition: Additional information about the agent.
|
294
294
|
# # @return [RDF::Vocabulary::Term]
|
295
295
|
# attr_reader :hasAgentNote
|
296
296
|
#
|
297
297
|
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
298
298
|
# #
|
299
|
-
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/agentType
|
300
|
-
# #
|
301
299
|
# # Definition: A high-level characterization of the type of agent.
|
300
|
+
# #
|
301
|
+
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/agentType
|
302
302
|
# # @return [RDF::Vocabulary::Term]
|
303
303
|
# attr_reader :hasAgentType
|
304
304
|
#
|
305
305
|
# # @return [RDF::Vocabulary::Term]
|
306
306
|
# attr_reader :hasApplicableDates
|
307
307
|
#
|
308
|
-
# #
|
308
|
+
# # Creation / Maintenance Notes: Composition level will generally be supplied by the repository, which should attempt to supply this value automatically. If the object was created by the repository, the creating routine knows the composition level and can supply this metadata. If the object is being ingested by the repository, repository programs will have to attempt to identify the composition level from the object itself or from externally supplied metadata.
|
309
309
|
# #
|
310
|
-
# #
|
310
|
+
# # Definition: An indication of whether the object is subject to one or more processes of decoding or unbundling.
|
311
311
|
# #
|
312
|
-
# #
|
312
|
+
# # Usage Notes: A file or bitstream can be subject to multiple encodings that must be decoded in reverse order (highest to lowest). For example, file A may be compressed to create file B, which is encrypted to create file C. To recreate a copy of the base file A, one would have to unencrypt file C to create file B and then uncompress file B to create file A. A compositionLevel of zero indicates that the object is a base object and not subject to further decoding, while a level of 1 or higher indicates that one or more decodings must be applied. Numbering goes lowest to highest (first encoded = 0). 0 is base object; 1-n are subsequent encodings. Use 0 as the default if there is only one compositionLevel. When multiple file objects are bundled together as filestreams within a package file object (e.g., a ZIP file), the individual filestream objects are not composition levels of the package file object. They should be considered separate objects, each with their own composition levels. For example, two encrypted files zipped together and stored in an archive as one file object would be described as three separate objects, each with its own associated metadata. The storage location of the two inner objects would point to the ZIP file, but the ZIP file itself would have only a single composition level (of zero) whose format would be “zip.”
|
313
313
|
# #
|
314
|
-
# #
|
314
|
+
# # Examples: 0, 1, 2
|
315
315
|
# #
|
316
|
-
# #
|
316
|
+
# # Rationale: A file or bitstream can be encoded with compression, encryption, etc., or bundled with other files or bitstreams into larger packages. Knowing the order in which these actions are taken is important if the original object or objects must be recovered.
|
317
317
|
# #
|
318
318
|
# # Data Constraints: Non-negative integers.
|
319
319
|
# # @return [RDF::Vocabulary::Term]
|
@@ -322,58 +322,58 @@ module RDF::Vocab
|
|
322
322
|
# # @return [RDF::Vocabulary::Term]
|
323
323
|
# attr_reader :hasContentLocation
|
324
324
|
#
|
325
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
326
|
+
# #
|
325
327
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/contentLocationType
|
326
328
|
# #
|
327
329
|
# # Rationale: To understand the meaning of the value it is necessary to know what location scheme is used.
|
328
330
|
# #
|
329
|
-
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
330
|
-
# #
|
331
331
|
# # Definition: The means of referencing the location of the content.
|
332
332
|
# # @return [RDF::Vocabulary::Term]
|
333
333
|
# attr_reader :hasContentLocationType
|
334
334
|
#
|
335
335
|
# # Definition: The reference to the location of the content used by the storage system.
|
336
336
|
# #
|
337
|
-
# # Usage Notes: This could be a fully qualified path and filename, or the information used by a resolution system (e.g., a handle) or the native information used by a storage management system. For a bitstream or filestream, this would probably be the reference point and offset of the starting position of the bitstream. It is up to the repository to determine the level of granularity that should be recorded.
|
338
|
-
# #
|
339
337
|
# # Examples: http://wwasearch.loc.gov/107th/200212107035/http://house.gov/langevin/ (file), c:\apache2\htdocs\index.html (file), 64 [offset from start of file c:\apache2\htdocs\image\logo.gif] (bitstream)
|
338
|
+
# #
|
339
|
+
# # Usage Notes: This could be a fully qualified path and filename, or the information used by a resolution system (e.g., a handle) or the native information used by a storage management system. For a bitstream or filestream, this would probably be the reference point and offset of the starting position of the bitstream. It is up to the repository to determine the level of granularity that should be recorded.
|
340
340
|
# # @return [RDF::Vocabulary::Term]
|
341
341
|
# attr_reader :hasContentLocationValue
|
342
342
|
#
|
343
|
-
# # Data Constraint: Values should be taken from ISO 3166.
|
344
|
-
# #
|
345
343
|
# # Definition: The country whose copyright laws apply.
|
346
344
|
# #
|
347
345
|
# # Rationale: Copyright law can vary from country to country.
|
348
346
|
# #
|
349
347
|
# # Examples: us, de, be
|
348
|
+
# #
|
349
|
+
# # Data Constraint: Values should be taken from ISO 3166.
|
350
350
|
# # @return [RDF::Vocabulary::Term]
|
351
351
|
# attr_reader :hasCopyrightJurisdiction
|
352
352
|
#
|
353
|
-
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/copyrightStatus
|
354
|
-
# #
|
355
353
|
# # Definition: A coded designation for the copyright status of the object at the time the rights statement is recorded.
|
356
354
|
# #
|
357
355
|
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
356
|
+
# #
|
357
|
+
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/copyrightStatus
|
358
358
|
# # @return [RDF::Vocabulary::Term]
|
359
359
|
# attr_reader :hasCopyrightStatus
|
360
360
|
#
|
361
|
-
# # Example: 2001-10-26T19:32:52+00:00
|
362
|
-
# #
|
363
361
|
# # Definition: The date that the copyright status recorded in copyrightStatus was determined.
|
364
362
|
# #
|
365
363
|
# # Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime
|
364
|
+
# #
|
365
|
+
# # Example: 2001-10-26T19:32:52+00:00
|
366
366
|
# # @return [RDF::Vocabulary::Term]
|
367
367
|
# attr_reader :hasCopyrightStatusDeterminationDate
|
368
368
|
#
|
369
369
|
# # @return [RDF::Vocabulary::Term]
|
370
370
|
# attr_reader :hasCreatingApplication
|
371
371
|
#
|
372
|
+
# # Example: MSWord
|
373
|
+
# #
|
372
374
|
# # Definition: A designation for the name of the software program that created the object.
|
373
375
|
# #
|
374
376
|
# # Usage Notes: The creatingApplication is the application that created the object in its current format, not the application that created the copy written to storage. For example, if a document is created by Microsoft Word and subsequently copied to archive storage by a repository’s Ingest program, the creatingApplication is Word, not the Ingest program.
|
375
|
-
# #
|
376
|
-
# # Example: MSWord
|
377
377
|
# # @return [RDF::Vocabulary::Term]
|
378
378
|
# attr_reader :hasCreatingApplicationName
|
379
379
|
#
|
@@ -383,13 +383,13 @@ module RDF::Vocab
|
|
383
383
|
# # @return [RDF::Vocabulary::Term]
|
384
384
|
# attr_reader :hasCreatingApplicationVersion
|
385
385
|
#
|
386
|
-
# # Example: 2001-10-26T19:32:52+00:00
|
387
|
-
# #
|
388
386
|
# # Definition: The actual or approximate date and time the object was created.
|
389
387
|
# #
|
390
388
|
# # Usage Notes: Use the most precise date available. This is the date the object was created by the creating application, not the date any copy was made externally or by the repository. For example, if a file is created by Microsoft Word in 2001 and two copies are made in 2003, the dateCreatedByApplication of all three files is 2001. The date a file is written to storage can be recorded as an Event. If the object itself contains internal creation and modification dates, the modification date should be used as dateCreatedByApplication. If the application is a Web harvester capturing an object at a point of time, use for date captured.
|
391
389
|
# #
|
392
390
|
# # Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime
|
391
|
+
# #
|
392
|
+
# # Example: 2001-10-26T19:32:52+00:00
|
393
393
|
# # @return [RDF::Vocabulary::Term]
|
394
394
|
# attr_reader :hasDateCreatedByApplication
|
395
395
|
#
|
@@ -404,44 +404,44 @@ module RDF::Vocab
|
|
404
404
|
# # @return [RDF::Vocabulary::Term]
|
405
405
|
# attr_reader :hasDependencyName
|
406
406
|
#
|
407
|
-
# # Usage Notes: Use “0000-00-00T00:00:00+00:00” for an open ended term of grant. Omit endDate if the ending date is unknown or the permission statement applies to many objects with different end dates.
|
408
|
-
# #
|
409
407
|
# # Definition: The ending date of the permission granted.
|
410
408
|
# #
|
411
409
|
# # Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime
|
410
|
+
# #
|
411
|
+
# # Usage Notes: Use “0000-00-00T00:00:00+00:00” for an open ended term of grant. Omit endDate if the ending date is unknown or the permission statement applies to many objects with different end dates.
|
412
412
|
# # @return [RDF::Vocabulary::Term]
|
413
413
|
# attr_reader :hasEndDate
|
414
414
|
#
|
415
415
|
# # @return [RDF::Vocabulary::Term]
|
416
416
|
# attr_reader :hasEnvironment
|
417
417
|
#
|
418
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
419
|
+
# #
|
418
420
|
# # Rationale: If multiple environments are described, this element can help to distinguish among them.
|
419
421
|
# #
|
420
422
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/environmentCharacteristic
|
421
423
|
# #
|
422
424
|
# # Definition: An assessment of the extent to which the described environment supports its purpose.
|
423
|
-
# #
|
424
|
-
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
425
425
|
# # @return [RDF::Vocabulary::Term]
|
426
426
|
# attr_reader :hasEnvironmentCharacteristic
|
427
427
|
#
|
428
|
-
# #
|
428
|
+
# # Definition: Additional information about the environment.
|
429
429
|
# #
|
430
430
|
# # Example: This environment assumes that the PDF will be stored locally and used with a standalone PDF reader.
|
431
431
|
# #
|
432
|
-
# #
|
432
|
+
# # Rationale: There may be a need to give a textual description of the environment for additional explanation.
|
433
433
|
# #
|
434
|
-
# #
|
434
|
+
# # Usage Notes: This note could be used to record the context of the environment information. For example, if a file can be rendered through a PC client application or through a browser with a plug-in, this note could be used to identify which situation applies. The note should not be used for a textual description of environment information recorded more rigorously elsewhere.
|
435
435
|
# # @return [RDF::Vocabulary::Term]
|
436
436
|
# attr_reader :hasEnvironmentNote
|
437
437
|
#
|
438
|
-
# #
|
438
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
439
439
|
# #
|
440
|
-
# #
|
440
|
+
# # Definition: The use(s) supported by the specified environment.
|
441
441
|
# #
|
442
442
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/environmentPurpose
|
443
443
|
# #
|
444
|
-
# #
|
444
|
+
# # Rationale: Different environments can support different uses of objects. For example, the environment needed to edit and modify a file can be quite different than the environment needed to render it.
|
445
445
|
# # @return [RDF::Vocabulary::Term]
|
446
446
|
# attr_reader :hasEnvironmentPurpose
|
447
447
|
#
|
@@ -451,70 +451,70 @@ module RDF::Vocab
|
|
451
451
|
# # @return [RDF::Vocabulary::Term]
|
452
452
|
# attr_reader :hasEvent
|
453
453
|
#
|
454
|
-
# #
|
454
|
+
# # Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime
|
455
455
|
# #
|
456
456
|
# # Example: 2001-10-26T19:32:52+00:00
|
457
457
|
# #
|
458
458
|
# # Definition: The single date and time, or date and time range, at or during which the event occurred.
|
459
459
|
# #
|
460
|
-
# #
|
460
|
+
# # Usage Notes: Recommended practice is to record the most specific time possible and to designate the time zone.
|
461
461
|
# # @return [RDF::Vocabulary::Term]
|
462
462
|
# attr_reader :hasEventDateTime
|
463
463
|
#
|
464
|
-
# #
|
464
|
+
# # Definition: Additional information about the event.
|
465
465
|
# #
|
466
466
|
# # Examples: Object permanently withdrawn by request of Caroline Hunt, Program=“MIGJP2JP2K”; version=“2.2”
|
467
467
|
# #
|
468
|
-
# #
|
468
|
+
# # Usage Notes: eventDetail is not intended to be processed by machine. It may record any information about an event and/or point to information stored elsewhere.
|
469
469
|
# # @return [RDF::Vocabulary::Term]
|
470
470
|
# attr_reader :hasEventDetail
|
471
471
|
#
|
472
472
|
# # Rationale: A coded way of representing the outcome of an event may be useful for machine processing and reporting. If, for example, a fixity check fails, the event record provides both an actionable and a permanent record.
|
473
473
|
# #
|
474
|
-
# #
|
474
|
+
# # Definition: A categorization of the overall result of the event in terms of success, partial success, or failure.
|
475
475
|
# #
|
476
476
|
# # Examples: 00 [a code meaning “action successfully completed”], CV-01 [a code meaning “checksum validated”]
|
477
477
|
# #
|
478
478
|
# # Data Constraint: Value should be taken from a controlled vocabulary.
|
479
479
|
# #
|
480
|
-
# #
|
480
|
+
# # Usage Notes: Recommended practice is to use a controlled vocabulary that a system can act upon automatically. More detail about the outcome may be recorded in eventOutcomeDetail. Recommended practice is to define events with sufficient granularity that each event has a single outcome.
|
481
481
|
# # @return [RDF::Vocabulary::Term]
|
482
482
|
# attr_reader :hasEventOutcome
|
483
483
|
#
|
484
484
|
# # @return [RDF::Vocabulary::Term]
|
485
485
|
# attr_reader :hasEventOutcomeDetail
|
486
486
|
#
|
487
|
-
# #
|
487
|
+
# # Definition: A detailed description of the result or product of the event in textual form.
|
488
488
|
# #
|
489
489
|
# # Examples: LZW compressed file, Non-standard tags found in header
|
490
490
|
# #
|
491
|
-
# #
|
491
|
+
# # Rationale: Additional information in textual form may be needed about the outcome of the event.
|
492
492
|
# # @return [RDF::Vocabulary::Term]
|
493
493
|
# attr_reader :hasEventOutcomeDetailNote
|
494
494
|
#
|
495
495
|
# # @return [RDF::Vocabulary::Term]
|
496
496
|
# attr_reader :hasEventOutcomeInformation
|
497
497
|
#
|
498
|
-
# # This propety links a Event instance to an Agent instance. Via this property a distinction can be made in the linkingAgent properties based on the domain.
|
499
|
-
# #
|
500
498
|
# # Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.
|
499
|
+
# #
|
500
|
+
# # This propety links a Event instance to an Agent instance. Via this property a distinction can be made in the linkingAgent properties based on the domain.
|
501
501
|
# # @return [RDF::Vocabulary::Term]
|
502
502
|
# attr_reader :hasEventRelatedAgent
|
503
503
|
#
|
504
|
-
# #
|
504
|
+
# # Definition: Information about an object associated with an event.
|
505
505
|
# #
|
506
506
|
# # Rationale: Digital provenance often requires that relationships between objects and events are documented.
|
507
507
|
# #
|
508
|
-
# #
|
508
|
+
# # Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.
|
509
509
|
# # @return [RDF::Vocabulary::Term]
|
510
510
|
# attr_reader :hasEventRelatedObject
|
511
511
|
#
|
512
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
513
|
+
# #
|
512
514
|
# # Rationale: Categorizing events will aid the preservation repository in machine processing of event information, particularly in reporting.
|
513
515
|
# #
|
514
516
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/eventType
|
515
517
|
# #
|
516
|
-
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
517
|
-
# #
|
518
518
|
# # Definition: A categorization of the nature of the event.
|
519
519
|
# # @return [RDF::Vocabulary::Term]
|
520
520
|
# attr_reader :hasEventType
|
@@ -538,13 +538,13 @@ module RDF::Vocab
|
|
538
538
|
# # @return [RDF::Vocabulary::Term]
|
539
539
|
# attr_reader :hasFormatName
|
540
540
|
#
|
541
|
-
# # Usage Notes: The formatNote may contain free text, a reference pointer, or a value from a controlled list.
|
542
|
-
# #
|
543
541
|
# # Definition: Additional information about format.
|
544
542
|
# #
|
545
|
-
# # Rationale: Qualifying information may be needed to supplement format designation and registry information or record a status for identification.
|
546
|
-
# #
|
547
543
|
# # Examples: tentative identification, disjunction, multiple format identifications found
|
544
|
+
# #
|
545
|
+
# # Usage Notes: The formatNote may contain free text, a reference pointer, or a value from a controlled list.
|
546
|
+
# #
|
547
|
+
# # Rationale: Qualifying information may be needed to supplement format designation and registry information or record a status for identification.
|
548
548
|
# # @return [RDF::Vocabulary::Term]
|
549
549
|
# attr_reader :hasFormatNote
|
550
550
|
#
|
@@ -565,97 +565,97 @@ module RDF::Vocab
|
|
565
565
|
# # @return [RDF::Vocabulary::Term]
|
566
566
|
# attr_reader :hasFormatRegistryName
|
567
567
|
#
|
568
|
-
# # Rationale: The same format may be defined in different registries for different purposes. For example, one registry may give detailed format specifications while another has profile information. If multiple registries are recorded, this semantic unit can be used to distinguish among them.
|
569
|
-
# #
|
570
568
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/formatRegistryRole
|
571
569
|
# #
|
572
570
|
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
573
571
|
# #
|
574
572
|
# # Definition: The purpose or expected use of the registry.
|
573
|
+
# #
|
574
|
+
# # Rationale: The same format may be defined in different registries for different purposes. For example, one registry may give detailed format specifications while another has profile information. If multiple registries are recorded, this semantic unit can be used to distinguish among them.
|
575
575
|
# # @return [RDF::Vocabulary::Term]
|
576
576
|
# attr_reader :hasFormatRegistryRole
|
577
577
|
#
|
578
|
-
# #
|
579
|
-
# #
|
580
|
-
# # Definition: The version of the format named in formatName.
|
578
|
+
# # Usage Notes: If the format is versioned, formatVersion should be recorded. It can be either a numeric or chronological designation.
|
581
579
|
# #
|
582
580
|
# # Rationale: Many authority lists of format names are not granular enough to indicate version, for example, MIME Media types.
|
583
581
|
# #
|
584
|
-
# #
|
582
|
+
# # Definition: The version of the format named in formatName.
|
583
|
+
# #
|
584
|
+
# # Examples: 6.0, 2003
|
585
585
|
# # @return [RDF::Vocabulary::Term]
|
586
586
|
# attr_reader :hasFormatVersion
|
587
587
|
#
|
588
588
|
# # @return [RDF::Vocabulary::Term]
|
589
589
|
# attr_reader :hasHardware
|
590
590
|
#
|
591
|
-
# # Usage Notes: Include manufacturer when this helps to identify or disambiguate the product. Include version for firmware or other components where that information is pertinent.
|
592
|
-
# #
|
593
591
|
# # Examples: Intel Pentium III, 1 GB DRAM, Windows XPcompatible joystick
|
594
592
|
# #
|
593
|
+
# # Usage Notes: Include manufacturer when this helps to identify or disambiguate the product. Include version for firmware or other components where that information is pertinent.
|
594
|
+
# #
|
595
595
|
# # Definition: Manufacturer, model, and version (if applicable) of the hardware.
|
596
596
|
# # @return [RDF::Vocabulary::Term]
|
597
597
|
# attr_reader :hasHardwareName
|
598
598
|
#
|
599
|
-
# # Usage Notes: This could be an identifier or URI used to point to hardware documentation.
|
600
|
-
# #
|
601
599
|
# # Definition: Additional requirements or instructions related to the hardware referenced in hwName.
|
602
600
|
# #
|
603
|
-
# # Examples: 32MB minimum, Required RAM for Apache is unknown
|
604
|
-
# #
|
605
601
|
# # Rationale: For hardware, the amount of computing resource needed (such as memory, storage, processor speed, etc.) may need to be documented. In addition, more detailed instructions may be needed to install and/or operate the hardware.
|
602
|
+
# #
|
603
|
+
# # Usage Notes: This could be an identifier or URI used to point to hardware documentation.
|
604
|
+
# #
|
605
|
+
# # Examples: 32MB minimum, Required RAM for Apache is unknown
|
606
606
|
# # @return [RDF::Vocabulary::Term]
|
607
607
|
# attr_reader :hasHardwareOtherInformation
|
608
608
|
#
|
609
|
-
# #
|
609
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
610
610
|
# #
|
611
611
|
# # Definition: Class or category of the hardware.
|
612
612
|
# #
|
613
|
-
# #
|
613
|
+
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/hardwareType
|
614
614
|
# # @return [RDF::Vocabulary::Term]
|
615
615
|
# attr_reader :hasHardwareType
|
616
616
|
#
|
617
617
|
# # @return [RDF::Vocabulary::Term]
|
618
618
|
# attr_reader :hasIdentifier
|
619
619
|
#
|
620
|
-
# # Usage Notes: The type of the identifier may be implicit within the repository as long it can be explicitly communicated when the item is disseminated outside of it.
|
621
|
-
# #
|
622
620
|
# # Rationale: Identifier values cannot be assumed to be unique across domains. The combination of identifierType and identifierValue should ensure uniqueness.
|
623
621
|
# #
|
624
622
|
# # Data Constraint: Value should be taken from controlled vocabulary.
|
625
623
|
# #
|
624
|
+
# # Usage Notes: The type of the identifier may be implicit within the repository as long it can be explicitly communicated when the item is disseminated outside of it.
|
625
|
+
# #
|
626
626
|
# # Definition: A designation of the domain within which the identifier is unique.
|
627
627
|
# #
|
628
628
|
# # Examples: DLC, DRS, hdl:4263537
|
629
629
|
# # @return [RDF::Vocabulary::Term]
|
630
630
|
# attr_reader :hasIdentifierType
|
631
631
|
#
|
632
|
-
# # Defnition: The value of the Identifier.
|
633
|
-
# #
|
634
632
|
# # Examples: 0000000312 (Representation), IU2440 (File), WAC1943.56 (File), http://nrs.harvard.edu/urn-3:FHCL.Loeb:sal (File), IU2440-1 (Bitstream)
|
633
|
+
# #
|
634
|
+
# # Defnition: The value of the Identifier.
|
635
635
|
# # @return [RDF::Vocabulary::Term]
|
636
636
|
# attr_reader :hasIdentifierValue
|
637
637
|
#
|
638
|
-
# #
|
638
|
+
# # Example: [DES decryption key]
|
639
639
|
# #
|
640
640
|
# # Definition: The decryption key or password.
|
641
641
|
# #
|
642
|
-
# #
|
642
|
+
# # Usage Notes: The key should be provided if known. However, it is not advisable to actually store the inhibitorKey in plain text in an unsecure database.
|
643
643
|
# # @return [RDF::Vocabulary::Term]
|
644
644
|
# attr_reader :hasInhibitorKey
|
645
645
|
#
|
646
|
+
# # Definition: The content or function protected by the inhibitor.
|
647
|
+
# #
|
646
648
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/inhibitorTarget
|
647
649
|
# #
|
648
650
|
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
649
|
-
# #
|
650
|
-
# # Definition: The content or function protected by the inhibitor.
|
651
651
|
# # @return [RDF::Vocabulary::Term]
|
652
652
|
# attr_reader :hasInhibitorTarget
|
653
653
|
#
|
654
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
655
|
+
# #
|
654
656
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/inhibitorType
|
655
657
|
# #
|
656
658
|
# # Definition: The inhibitor method employed.
|
657
|
-
# #
|
658
|
-
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
659
659
|
# # @return [RDF::Vocabulary::Term]
|
660
660
|
# attr_reader :hasInhibitorType
|
661
661
|
#
|
@@ -677,54 +677,54 @@ module RDF::Vocab
|
|
677
677
|
# # @return [RDF::Vocabulary::Term]
|
678
678
|
# attr_reader :hasLicenseTerms
|
679
679
|
#
|
680
|
+
# # Example: 7c9b35da4f2ebd436f1cf88e5a39b3a257edf4a22be3c955ac49da2e2107b67a1924419563
|
681
|
+
# #
|
680
682
|
# # Definition: The output of the message digest algorithm.
|
681
683
|
# #
|
682
684
|
# # Rationale: This must be stored so that it can be compared in future fixity checks.
|
683
|
-
# #
|
684
|
-
# # Example: 7c9b35da4f2ebd436f1cf88e5a39b3a257edf4a22be3c955ac49da2e2107b67a1924419563
|
685
685
|
# # @return [RDF::Vocabulary::Term]
|
686
686
|
# attr_reader :hasMessageDigest
|
687
687
|
#
|
688
|
-
# # Definition: The specific algorithm used to construct the message digest for the digital object.
|
689
|
-
# #
|
690
688
|
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
691
689
|
# #
|
692
690
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/cryptographicHashFunctions
|
691
|
+
# #
|
692
|
+
# # Definition: The specific algorithm used to construct the message digest for the digital object.
|
693
693
|
# # @return [RDF::Vocabulary::Term]
|
694
694
|
# attr_reader :hasMessageDigestAlgorithm
|
695
695
|
#
|
696
|
-
# # Rationale: A preservation repository may ingest files that have had message digests calculated by the submitter; checking these ensures that the file as received is the same as the file as sent. The repository may also ingest files that do not have message digests, and so must calculate the initial value upon ingest. It can be useful to know who calculated the initial value of the message digest.
|
697
|
-
# #
|
698
696
|
# # Usage Notes: The originator of the message digest could be represented by a string representing the agent (e.g., “NRS” referring to the archive itself) or a pointer to an agent description (e.g., “A0000987” taken here to be an agentIdentifierValue).
|
699
697
|
# #
|
700
|
-
# # Examples: DRS, A0000978
|
701
|
-
# #
|
702
698
|
# # Definition: The agent that created the original message digest that is compared in a fixity check.
|
703
699
|
# #
|
704
700
|
# # Creation / Maintenance Notes: If the calculation of the initial message digest is treated by the repository as an Event, this information could be obtained from an Event record.
|
701
|
+
# #
|
702
|
+
# # Examples: DRS, A0000978
|
703
|
+
# #
|
704
|
+
# # Rationale: A preservation repository may ingest files that have had message digests calculated by the submitter; checking these ensures that the file as received is the same as the file as sent. The repository may also ingest files that do not have message digests, and so must calculate the initial value upon ingest. It can be useful to know who calculated the initial value of the message digest.
|
705
705
|
# # @return [RDF::Vocabulary::Term]
|
706
706
|
# attr_reader :hasMessageDigestOriginator
|
707
707
|
#
|
708
708
|
# # Definition: Information about an object associated with an event or rightsstatement.
|
709
709
|
# #
|
710
|
-
# # Rationale: Digital provenance often requires that relationships between objects and events are documented. / Rights statements must be associated with the objects to which they pertain, either by linking from the rights statement to the object(s) or by linking from the object(s) to the rights statement. This provides the mechanism for the link from the rights statement to an object. For denoting the role of the object, when related to an event,one can extend this ontology be defining your own subproperties, such as those given by http://id.loc.gov/vocabulary/preservation/eventRelatedObjectRole.
|
711
|
-
# #
|
712
710
|
# # Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.
|
711
|
+
# #
|
712
|
+
# # Rationale: Digital provenance often requires that relationships between objects and events are documented. / Rights statements must be associated with the objects to which they pertain, either by linking from the rights statement to the object(s) or by linking from the object(s) to the rights statement. This provides the mechanism for the link from the rights statement to an object. For denoting the role of the object, when related to an event,one can extend this ontology be defining your own subproperties, such as those given by http://id.loc.gov/vocabulary/preservation/eventRelatedObjectRole.
|
713
713
|
# # @return [RDF::Vocabulary::Term]
|
714
714
|
# attr_reader :hasObject
|
715
715
|
#
|
716
716
|
# # @return [RDF::Vocabulary::Term]
|
717
717
|
# attr_reader :hasObjectCharacteristics
|
718
718
|
#
|
719
|
-
# #
|
719
|
+
# # Creation / Maintenance Notes: This value would always be supplied to the repository by the submitter or harvesting application. How much of the file path to preserve would be up to the repository.
|
720
720
|
# #
|
721
721
|
# # Definition: The name of the object as submitted to or harvested by the repository, before any renaming by the repository.
|
722
722
|
# #
|
723
|
-
# #
|
723
|
+
# # Example: N419.pdf
|
724
724
|
# #
|
725
|
-
# #
|
725
|
+
# # Usage Notes: This is the name of the object as designated in the Submission Information Package (SIP). The object may have other names in different contexts. When two repositories are exchanging content, it would be important for the receiving repository to know and record the name of the representation at the originating repository. In the case of representations, this may be a directory name.
|
726
726
|
# #
|
727
|
-
# #
|
727
|
+
# # Rationale: The name used within the preservation repository may not be known outside of the repository. A depositor might need to request a file by its original name. Also, the repository may need to reconstruct internal links for dissemination.
|
728
728
|
# # @return [RDF::Vocabulary::Term]
|
729
729
|
# attr_reader :hasOriginalName
|
730
730
|
#
|
@@ -735,9 +735,9 @@ module RDF::Vocab
|
|
735
735
|
# #
|
736
736
|
# # Rationale: The preservationLevel applicable to an object is expected to be reviewed and changed over time, in response to changes in repository preservation requirements, policies, or capabilities relevant to the object. The date that the current preservationLevelValue was assigned aids review of decisions.
|
737
737
|
# #
|
738
|
-
# # Definition: The date, or date and time, when a particular preservationLevelValue was assigned to the object.
|
739
|
-
# #
|
740
738
|
# # Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime
|
739
|
+
# #
|
740
|
+
# # Definition: The date, or date and time, when a particular preservationLevelValue was assigned to the object.
|
741
741
|
# # @return [RDF::Vocabulary::Term]
|
742
742
|
# attr_reader :hasPreservationLevelDateAssigned
|
743
743
|
#
|
@@ -751,27 +751,27 @@ module RDF::Vocab
|
|
751
751
|
# # @return [RDF::Vocabulary::Term]
|
752
752
|
# attr_reader :hasPreservationLevelRationale
|
753
753
|
#
|
754
|
-
# #
|
755
|
-
# #
|
756
|
-
# # Definition: A value indicating the context in which a set of preservation options is applicable.
|
754
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
757
755
|
# #
|
758
756
|
# # Rationale: Repositories may assign preservationLevelValues in different contexts which must be differentiated, and may need to record more than one context.
|
759
757
|
# #
|
760
|
-
# #
|
758
|
+
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/preservationLevelRole
|
759
|
+
# #
|
760
|
+
# # Definition: A value indicating the context in which a set of preservation options is applicable.
|
761
761
|
# # @return [RDF::Vocabulary::Term]
|
762
762
|
# attr_reader :hasPreservationLevelRole
|
763
763
|
#
|
764
764
|
# # Usage Notes: Only one preservationLevelValue may be recorded per preservationLevel container. If a further preservationLevelValue applies to the object in a different context, a separate preservationLevel container should be repeated.
|
765
765
|
# #
|
766
|
+
# # Creation / Maintenance Notes: The preservation level may be assigned by the repository or requested by the depositor and submitted as metadata.
|
767
|
+
# #
|
768
|
+
# # Data Constraint: Value should be taken from a controlled vocabulary.
|
769
|
+
# #
|
766
770
|
# # Rationale: Some preservation repositories will offer multiple preservation options depending on factors such as the value or uniqueness of the material, the “preservability” of the format, the amount the customer is willing to pay, etc.
|
767
771
|
# #
|
768
772
|
# # Examples: bit-level, full, fully supported with future migrations (File), 0
|
769
773
|
# #
|
770
|
-
# # Data Constraint: Value should be taken from a controlled vocabulary.
|
771
|
-
# #
|
772
774
|
# # Definition: A value indicating the set of preservation functions expected to be applied to the object.
|
773
|
-
# #
|
774
|
-
# # Creation / Maintenance Notes: The preservation level may be assigned by the repository or requested by the depositor and submitted as metadata.
|
775
775
|
# # @return [RDF::Vocabulary::Term]
|
776
776
|
# attr_reader :hasPreservationLevelValue
|
777
777
|
#
|
@@ -779,9 +779,9 @@ module RDF::Vocab
|
|
779
779
|
# # @return [RDF::Vocabulary::Term]
|
780
780
|
# attr_reader :hasRelatedObject
|
781
781
|
#
|
782
|
-
# # Definition: The order of the related object relative to other objects with the same type of relationship.
|
783
|
-
# #
|
784
782
|
# # Rationale: This semantic unit is particularly useful for structural relationships. In order to reconstruct a representation, it may be necessary to know the order of components with sibling or part-whole relationships. For example, to render a page-image book, it is necessary to know the order of files representing pages.
|
783
|
+
# #
|
784
|
+
# # Definition: The order of the related object relative to other objects with the same type of relationship.
|
785
785
|
# # @return [RDF::Vocabulary::Term]
|
786
786
|
# attr_reader :hasRelatedObjectSequence
|
787
787
|
#
|
@@ -789,11 +789,11 @@ module RDF::Vocab
|
|
789
789
|
# # @return [RDF::Vocabulary::Term]
|
790
790
|
# attr_reader :hasRelatedStatuteInformation
|
791
791
|
#
|
792
|
-
# #
|
792
|
+
# # Definition: This property links one object to one or more other objects.
|
793
793
|
# #
|
794
794
|
# # Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.
|
795
795
|
# #
|
796
|
-
# #
|
796
|
+
# # The LOC will provide a SKOS vocabulary, where the concepts can also be used as object properties at http://id.loc.gov/. These relationships will capture the relationship type and subtype. One can define its own relationships, but for interoperability reasons, these should be linked to or made a subproperty of the properties of the LOC vocabulary.
|
797
797
|
# # @return [RDF::Vocabulary::Term]
|
798
798
|
# attr_reader :hasRelationship
|
799
799
|
#
|
@@ -806,20 +806,20 @@ module RDF::Vocab
|
|
806
806
|
# # @return [RDF::Vocabulary::Term]
|
807
807
|
# attr_reader :hasRightsDocumentation
|
808
808
|
#
|
809
|
-
# # Definition: This property denotes the role of the related documentation. The value must be taken from a skos vocabulary. A value indicating the purpose or expected use of the documentation being identified.
|
810
|
-
# #
|
811
809
|
# # Rationale: This information distinguishes the purpose of the supporting documentation especially when there are multiple documentation identifiers.
|
810
|
+
# #
|
811
|
+
# # Definition: This property denotes the role of the related documentation. The value must be taken from a skos vocabulary. A value indicating the purpose or expected use of the documentation being identified.
|
812
812
|
# # @return [RDF::Vocabulary::Term]
|
813
813
|
# attr_reader :hasRightsDocumentationRole
|
814
814
|
#
|
815
815
|
# # @return [RDF::Vocabulary::Term]
|
816
816
|
# attr_reader :hasRightsGranted
|
817
817
|
#
|
818
|
-
# # Usage Notes: This semantic unit may include a statement about risk assessment, for example, when a repository is not certain about what permissions have been granted.
|
819
|
-
# #
|
820
818
|
# # Definition: Additional information about the rights granted.
|
821
819
|
# #
|
822
820
|
# # Rationale: A textual description of the rights granted may be needed for additional explanation.
|
821
|
+
# #
|
822
|
+
# # Usage Notes: This semantic unit may include a statement about risk assessment, for example, when a repository is not certain about what permissions have been granted.
|
823
823
|
# # @return [RDF::Vocabulary::Term]
|
824
824
|
# attr_reader :hasRightsGrantedNote
|
825
825
|
#
|
@@ -844,23 +844,23 @@ module RDF::Vocab
|
|
844
844
|
# # @return [RDF::Vocabulary::Term]
|
845
845
|
# attr_reader :hasSignature
|
846
846
|
#
|
847
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
848
|
+
# #
|
847
849
|
# # Definition: The encoding used for the values of signatureValue, keyInformation.
|
848
850
|
# #
|
849
851
|
# # Rationale: These values cannot be interpreted correctly if the encoding is unknown.
|
850
852
|
# #
|
851
853
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/signatureEncoding
|
852
|
-
# #
|
853
|
-
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
854
854
|
# # @return [RDF::Vocabulary::Term]
|
855
855
|
# attr_reader :hasSignatureEncoding
|
856
856
|
#
|
857
|
-
# #
|
858
|
-
# #
|
859
|
-
# # Rationale: The same algorithms must be used for signature validation.
|
857
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
860
858
|
# #
|
861
859
|
# # Data Constraint: Values are taken from a SKOS vocabulary
|
862
860
|
# #
|
863
|
-
# #
|
861
|
+
# # Definition: A designation for the encryption and hash algorithms used for signature generation.
|
862
|
+
# #
|
863
|
+
# # Rationale: The same algorithms must be used for signature validation.
|
864
864
|
# # @return [RDF::Vocabulary::Term]
|
865
865
|
# attr_reader :hasSignatureMethod
|
866
866
|
#
|
@@ -870,11 +870,11 @@ module RDF::Vocab
|
|
870
870
|
# # @return [RDF::Vocabulary::Term]
|
871
871
|
# attr_reader :hasSignatureProperties
|
872
872
|
#
|
873
|
+
# # Usage Notes: This may include the canonicalization method used before calculating the message digest, if the object was normalized before signing. This value could also be a pointer to archive documentation.
|
874
|
+
# #
|
873
875
|
# # Definition: The operations to be performed in order to validate the digital signature.
|
874
876
|
# #
|
875
877
|
# # Rationale: The repository should not assume that the procedure for validating any particular signature will be known many years in the future without documentation.
|
876
|
-
# #
|
877
|
-
# # Usage Notes: This may include the canonicalization method used before calculating the message digest, if the object was normalized before signing. This value could also be a pointer to archive documentation.
|
878
878
|
# # @return [RDF::Vocabulary::Term]
|
879
879
|
# attr_reader :hasSignatureValidationRules
|
880
880
|
#
|
@@ -884,46 +884,46 @@ module RDF::Vocab
|
|
884
884
|
# # @return [RDF::Vocabulary::Term]
|
885
885
|
# attr_reader :hasSignatureValue
|
886
886
|
#
|
887
|
-
# #
|
887
|
+
# # Usage Notes: If the signer is an Agent known to the repository, this property can directly link to this agent. The consequence is punning: a datatype property and object property with the same name, i.e., :signer
|
888
888
|
# #
|
889
889
|
# # Definition: The individual, institution, or authority responsible for generating the signature.
|
890
890
|
# #
|
891
|
-
# #
|
891
|
+
# # Rationale: The signer might also be carried in the keyInformation, but it can be accessed more conveniently if recorded here.
|
892
892
|
# # @return [RDF::Vocabulary::Term]
|
893
893
|
# attr_reader :hasSigner
|
894
894
|
#
|
895
895
|
# # @return [RDF::Vocabulary::Term]
|
896
896
|
# attr_reader :hasSignificantProperties
|
897
897
|
#
|
898
|
-
# #
|
898
|
+
# # Usage Notes: This semantic unit is optional and may be used as part of a facet:detail pair with significantPropertiesValue.
|
899
899
|
# #
|
900
|
-
# #
|
900
|
+
# # Definition: The aspect, facet, or attribute of an object about which significant properties are being described.
|
901
901
|
# #
|
902
902
|
# # Rationale: Repositories may choose to describe significant properties based on a particular aspect or attribute of an object.
|
903
903
|
# #
|
904
|
-
# #
|
904
|
+
# # Examples: content, structure, behavior, page count, page width, typeface, hyperlinks (representation), image count (representation), color space [for an embedded image] (bitstream)
|
905
905
|
# # @return [RDF::Vocabulary::Term]
|
906
906
|
# attr_reader :hasSignificantPropertiesType
|
907
907
|
#
|
908
908
|
# # Definition: Description of the characteristics of a particular object subjectively determined to be important to maintain through preservation actions.
|
909
909
|
# #
|
910
|
-
# # Usage Notes: If facet:detail pairs are used, the content of significantPropertiesValue should describe the significant properties of object relevant to the aspect, facet, or attribute declared in the significantPropertiesType with which it is paired. If facet:detail pairs are not used, significantPropertiesValue may be used to freely describe any characteristic of an object. significantPropertiesValue is not repeatable. Multiple significant properties should be described in separate, repeated significantProperties container units.
|
911
|
-
# #
|
912
910
|
# # Examples: [For a Web page containing animation that is not considered essential] Content only, [For detail associated with a significantPropertiesType of "behavior"] Hyperlinks traversable, [For a Word document with embedded links that are not considered essential] Content only, [For detail associated with significantPropertiesType of "behavior"] Editable, [For detail associated with a significantPropertiesType of "page width"] 210 mm, [For a PDF with an embedded graph, where the lines' color determines the lines' meaning] Color, [For detail associated with a significantPropertiesType of "appearance"] Color
|
913
911
|
# #
|
914
912
|
# # Rationale: Repositories may choose to describe significant properties based on a particular aspect or attribute of an object.
|
913
|
+
# #
|
914
|
+
# # Usage Notes: If facet:detail pairs are used, the content of significantPropertiesValue should describe the significant properties of object relevant to the aspect, facet, or attribute declared in the significantPropertiesType with which it is paired. If facet:detail pairs are not used, significantPropertiesValue may be used to freely describe any characteristic of an object. significantPropertiesValue is not repeatable. Multiple significant properties should be described in separate, repeated significantProperties container units.
|
915
915
|
# # @return [RDF::Vocabulary::Term]
|
916
916
|
# attr_reader :hasSignificantPropertiesValue
|
917
917
|
#
|
918
918
|
# # Definition: The size in bytes of the file or bitstream stored in the repository.
|
919
919
|
# #
|
920
|
-
# #
|
920
|
+
# # Creation / Maintenance Notes: Automatically obtained by the repository.
|
921
921
|
# #
|
922
922
|
# # Example: 2038937
|
923
923
|
# #
|
924
924
|
# # Rationale: Size is useful for ensuring the correct number of bytes from storage have been retrieved and that an application has enough room to move or process files. It might also be used when billing for storage.
|
925
925
|
# #
|
926
|
-
# #
|
926
|
+
# # Usage Notes: Defining this semantic unit as size in bytes makes it unnecessary to record a unit of measurement. However, for the purpose of data exchange the unit of measurement should be stated or understood by both partners.
|
927
927
|
# # @return [RDF::Vocabulary::Term]
|
928
928
|
# attr_reader :hasSize
|
929
929
|
#
|
@@ -932,35 +932,35 @@ module RDF::Vocab
|
|
932
932
|
#
|
933
933
|
# # Example: GNU gcc >=2.7.2
|
934
934
|
# #
|
935
|
-
# # Usage Notes: The value should be constructed in a way that is consistent with the construction of swName and swVersion. This semantic unit identifies the software that is needed by what is recorded in swName, for example, a Perl script that depends on a Perl module. In this case the Perl script is listed in swName, with the module in swDependency within a software container.
|
936
|
-
# #
|
937
935
|
# # Definition: The name and, if applicable, version of any software component needed by the software referenced in swName in the context of using this object.
|
936
|
+
# #
|
937
|
+
# # Usage Notes: The value should be constructed in a way that is consistent with the construction of swName and swVersion. This semantic unit identifies the software that is needed by what is recorded in swName, for example, a Perl script that depends on a Perl module. In this case the Perl script is listed in swName, with the module in swDependency within a software container.
|
938
938
|
# # @return [RDF::Vocabulary::Term]
|
939
939
|
# attr_reader :hasSoftwareDependency
|
940
940
|
#
|
941
|
-
# #
|
941
|
+
# # Examples: Adobe Photoshop, Adobe Acrobat Reader
|
942
942
|
# #
|
943
943
|
# # Usage Notes: Include manufacturer when this helps to identify or disambiguate the product, for example, use “Adobe Photoshop” rather than “Photoshop.”
|
944
944
|
# #
|
945
|
-
# #
|
945
|
+
# # Definition: Manufacturer and title of the software application.
|
946
946
|
# # @return [RDF::Vocabulary::Term]
|
947
947
|
# attr_reader :hasSoftwareName
|
948
948
|
#
|
949
|
+
# # Usage Notes: This could be a reliable persistent identifier or URI pointing to software documentation within or outside the repository.
|
950
|
+
# #
|
949
951
|
# # Example: Install Acroread (Adobe Acrobat) first; copy nppdf.so (the plug-in) to your Mozilla plug-ins directory, and make sure a copy of (or symlink to) Acroread is in your PATH.
|
950
952
|
# #
|
951
953
|
# # Definition: Additional requirements or instructions related to the software referenced in swName.
|
952
|
-
# #
|
953
|
-
# # Usage Notes: This could be a reliable persistent identifier or URI pointing to software documentation within or outside the repository.
|
954
954
|
# # @return [RDF::Vocabulary::Term]
|
955
955
|
# attr_reader :hasSoftwareOtherInformation
|
956
956
|
#
|
957
|
-
# #
|
957
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
958
958
|
# #
|
959
|
-
# #
|
959
|
+
# # Rationale: Several different layers of software can be required to support an object.
|
960
960
|
# #
|
961
961
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/softwareType
|
962
962
|
# #
|
963
|
-
# #
|
963
|
+
# # Definition: Class or category of software.
|
964
964
|
# # @return [RDF::Vocabulary::Term]
|
965
965
|
# attr_reader :hasSoftwareType
|
966
966
|
#
|
@@ -978,30 +978,30 @@ module RDF::Vocab
|
|
978
978
|
# # @return [RDF::Vocabulary::Term]
|
979
979
|
# attr_reader :hasStartDate
|
980
980
|
#
|
981
|
-
# #
|
981
|
+
# # Definition: An identifying designation for the statute.
|
982
982
|
# #
|
983
983
|
# # Usage Notes: Use standard citation form when applicable.
|
984
984
|
# #
|
985
|
-
# #
|
985
|
+
# # Examples: Legal Deposit (Jersey) Law 200, National Library of New Zealand (Te Puna Mātauranga o Aotearoa) Act 2003 no 19 part 4 s 34
|
986
986
|
# # @return [RDF::Vocabulary::Term]
|
987
987
|
# attr_reader :hasStatuteCitation
|
988
988
|
#
|
989
|
-
# #
|
989
|
+
# # Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime
|
990
990
|
# #
|
991
|
-
# #
|
991
|
+
# # Definition: The date that the determination was made that the statute authorized the permission(s) noted.
|
992
992
|
# #
|
993
993
|
# # Example: 2001-10-26T19:32:52+00:00
|
994
994
|
# #
|
995
|
-
# #
|
995
|
+
# # Rationale: The permission in question may be the subject of some interpretation. These assessments are made within a specific context and at a specific time. At another time the context, and therefore the assessment, could change. For this reason it can be important to record the date of the decision.
|
996
996
|
# # @return [RDF::Vocabulary::Term]
|
997
997
|
# attr_reader :hasStatuteInformationDeterminationDate
|
998
998
|
#
|
999
999
|
# # Data Constraint: Values should be taken from a controlled vocabulary.
|
1000
1000
|
# #
|
1001
|
-
# # Definition: The country or other political body enacting the statute.
|
1002
|
-
# #
|
1003
1001
|
# # Rationale: The connection between the object and the rights granted is based on jurisdiction.
|
1004
1002
|
# #
|
1003
|
+
# # Definition: The country or other political body enacting the statute.
|
1004
|
+
# #
|
1005
1005
|
# # Examples: us, de, be
|
1006
1006
|
# # @return [RDF::Vocabulary::Term]
|
1007
1007
|
# attr_reader :hasStatuteJurisdiction
|
@@ -1009,13 +1009,13 @@ module RDF::Vocab
|
|
1009
1009
|
# # @return [RDF::Vocabulary::Term]
|
1010
1010
|
# attr_reader :hasStorage
|
1011
1011
|
#
|
1012
|
-
# # Rationale: The repository needs to know the medium on which an object is stored in order to know how and when to do media refreshment and media migration.
|
1013
|
-
# #
|
1014
1012
|
# # Definition: The physical medium on which the object is stored (e.g., magnetic tape, hard disk, CD-ROM, DVD).
|
1015
1013
|
# #
|
1016
|
-
# #
|
1014
|
+
# # Rationale: The repository needs to know the medium on which an object is stored in order to know how and when to do media refreshment and media migration.
|
1017
1015
|
# #
|
1018
1016
|
# # Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/storageMedium
|
1017
|
+
# #
|
1018
|
+
# # Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.
|
1019
1019
|
# # @return [RDF::Vocabulary::Term]
|
1020
1020
|
# attr_reader :hasStorageMedium
|
1021
1021
|
#
|
@@ -1030,9 +1030,7 @@ module RDF::Vocab
|
|
1030
1030
|
|
1031
1031
|
# Ontology definition
|
1032
1032
|
ontology :"http://www.loc.gov/premis/rdf/v1#",
|
1033
|
-
comment:
|
1034
|
-
This ontology identifies the classes and properties used to describe preservation metadata in RDF.
|
1035
|
-
It aligns with PREMIS Data Dictionary version 2.2.).freeze,
|
1033
|
+
comment: "\n This ontology identifies the classes and properties used to describe preservation metadata in RDF.\n It aligns with PREMIS Data Dictionary version 2.2.".freeze,
|
1036
1034
|
"dc:modified": "2012-09-14T00:00:00Z".freeze,
|
1037
1035
|
isDefinedBy: "http://www.loc.gov/standards/premis/v2/premis-2-2.pdf".freeze,
|
1038
1036
|
label: "Preservation Metadata: Implementation Strategies (PREMIS) Ontology".freeze,
|
@@ -1043,17 +1041,12 @@ module RDF::Vocab
|
|
1043
1041
|
|
1044
1042
|
# Class definitions
|
1045
1043
|
term :Agent,
|
1046
|
-
comment: [
|
1047
|
-
May hold or grant one or more rights.
|
1048
|
-
May carry out, authorize, or compel one or more events.
|
1049
|
-
May create or act upon one or more objects through an event or with respect to a rights statement.).freeze, %(The Agent entity aggregates information about attributes or characteristics of agents \(persons, organizations, or software\) associated with rights management and preservation events in the life of a data object. Agent information serves to identify an agent unambiguously from all other
|
1050
|
-
Agent entities.).freeze],
|
1044
|
+
comment: ["Entity properties:\nMay hold or grant one or more rights.\nMay carry out, authorize, or compel one or more events.\nMay create or act upon one or more objects through an event or with respect to a rights statement.".freeze, "The Agent entity aggregates information about attributes or characteristics of agents (persons, organizations, or software) associated with rights management and preservation events in the life of a data object. Agent information serves to identify an agent unambiguously from all other\nAgent entities.".freeze],
|
1051
1045
|
subClassOf: ["dc:Agent".freeze, "foaf:Agent".freeze, "premis:PremisEntity".freeze],
|
1052
1046
|
type: "owl:Class".freeze,
|
1053
1047
|
"vs:term_status": "stable".freeze
|
1054
1048
|
term :ApplicableDates,
|
1055
|
-
comment: [
|
1056
|
-
applied to the content.).freeze, %(Rationale Specific dates may apply to the particular rights statement.).freeze],
|
1049
|
+
comment: ["Definition: The date range during which the particular rights statement applies or is\napplied to the content.".freeze, "Rationale Specific dates may apply to the particular rights statement.".freeze],
|
1057
1050
|
subClassOf: [term(
|
1058
1051
|
maxCardinality: "1".freeze,
|
1059
1052
|
onProperty: "premis:hasEndDate".freeze,
|
@@ -1066,7 +1059,7 @@ applied to the content.).freeze, %(Rationale Specific dates may apply to the par
|
|
1066
1059
|
type: "owl:Class".freeze,
|
1067
1060
|
"vs:term_status": "stable".freeze
|
1068
1061
|
term :Bitstream,
|
1069
|
-
comment:
|
1062
|
+
comment: "Definition: Contiguous or non-contiguous data within a file that has meaningful properties for preservation purposes.".freeze,
|
1070
1063
|
"rdfs:seeAlso": "Object class definition".freeze,
|
1071
1064
|
subClassOf: ["premis:Object".freeze, term(
|
1072
1065
|
minCardinality: "1".freeze,
|
@@ -1076,7 +1069,7 @@ applied to the content.).freeze, %(Rationale Specific dates may apply to the par
|
|
1076
1069
|
type: "owl:Class".freeze,
|
1077
1070
|
"vs:term_status": "stable".freeze
|
1078
1071
|
term :ContentLocation,
|
1079
|
-
comment: [
|
1072
|
+
comment: ["Creation / Maintenance Notes: A preservation repository should never refer to content that it does not control. Therefore, the PREMIS working group assumed that the repository will always assign the contentLocation, probably by program.".freeze, "Definition: Information needed to retrieve a file from the storage system, or to access a bitstream within a file.".freeze, "Usage Notes: If the preservation repository uses the objectIdentifier as a handle for retrieving data, contentLocation is implicit and does not need to be recorded.".freeze],
|
1080
1073
|
subClassOf: term(
|
1081
1074
|
intersectionOf: list(term(
|
1082
1075
|
cardinality: "1".freeze,
|
@@ -1092,8 +1085,7 @@ applied to the content.).freeze, %(Rationale Specific dates may apply to the par
|
|
1092
1085
|
type: "owl:Class".freeze,
|
1093
1086
|
"vs:term_status": "stable".freeze
|
1094
1087
|
term :CopyrightInformation,
|
1095
|
-
comment: [
|
1096
|
-
Repositories may need to extend this with more detailed information. See the California Digital Library's copyrightMD schema \(www.cdlib.org/inside/projects/rights/schema/\) for an example of a more detailed scheme.).freeze],
|
1088
|
+
comment: ["Definition: Information about the copyright status of the object(s).".freeze, "Usage Notes: When rights basis is a copyright, copyrightInformation should be provided.\nRepositories may need to extend this with more detailed information. See the California Digital Library's copyrightMD schema (www.cdlib.org/inside/projects/rights/schema/) for an example of a more detailed scheme.".freeze],
|
1097
1089
|
subClassOf: ["premis:RightsStatement".freeze, term(
|
1098
1090
|
intersectionOf: list(term(
|
1099
1091
|
cardinality: "1".freeze,
|
@@ -1109,12 +1101,7 @@ Repositories may need to extend this with more detailed information. See the Cal
|
|
1109
1101
|
type: "owl:Class".freeze,
|
1110
1102
|
"vs:term_status": "stable".freeze
|
1111
1103
|
term :CreatingApplication,
|
1112
|
-
comment: [
|
1113
|
-
If the object was created outside the repository, it is possible this information could be supplied by the depositor. It might also be extracted from the file itself; the name of the creating application is often embedded within the file.).freeze, %(Definition: Information about the application that created the object.).freeze, %(Rationale: Information about the creating application, including the version of the application and the date the file was created, can be useful for problem solving purposes. For example, it is not uncommon for certain versions of software to be known for causing conversion errors or introducing artifacts. It is also useful to determine which rendering software is available for the digital object. For example, if you know that the Distiller program created the PDF file, you know it will be renderable with \(among other programs\) Adobe Reader.).freeze, %(Usage Notes: This semantic unit applies to both objects created external to the repository and subsequently ingested, and to objects created by the repository, for example, through migration events.
|
1114
|
-
The creatingApplication container is repeatable if more than one application processed the object in turn. For example, a file could be created by Microsoft Word and later turned into a PDF using Adobe Acrobat. Details of both the Word and Acrobat applications may be recorded. However, if both files are stored in the repository, each file should be completely described as an Object entity and linked by using relationship information with a relationshipType “derivation.”
|
1115
|
-
It may also be repeated to record the creating application before the object was ingested as well as the creating application used as part of the ingest process. For example, an HTML file was created pre-ingest using Dreamweaver, and the Web crawler Heritrix then captured a snapshot of the files as part of the ingest.
|
1116
|
-
The amount of information needed for creatingApplication given here is minimal. For more granularity, extensibility is provided.
|
1117
|
-
Rather than having each repository record this locally, it would be preferable to have a registry of this information similar to format or environment registries.).freeze],
|
1104
|
+
comment: ["Creation / Maintenance Notes: If the object was created by the repository, assignment of creating application information should be straightforward.\nIf the object was created outside the repository, it is possible this information could be supplied by the depositor. It might also be extracted from the file itself; the name of the creating application is often embedded within the file.".freeze, "Definition: Information about the application that created the object.".freeze, "Rationale: Information about the creating application, including the version of the application and the date the file was created, can be useful for problem solving purposes. For example, it is not uncommon for certain versions of software to be known for causing conversion errors or introducing artifacts. It is also useful to determine which rendering software is available for the digital object. For example, if you know that the Distiller program created the PDF file, you know it will be renderable with (among other programs) Adobe Reader.".freeze, "Usage Notes: This semantic unit applies to both objects created external to the repository and subsequently ingested, and to objects created by the repository, for example, through migration events.\nThe creatingApplication container is repeatable if more than one application processed the object in turn. For example, a file could be created by Microsoft Word and later turned into a PDF using Adobe Acrobat. Details of both the Word and Acrobat applications may be recorded. However, if both files are stored in the repository, each file should be completely described as an Object entity and linked by using relationship information with a relationshipType “derivation.”\nIt may also be repeated to record the creating application before the object was ingested as well as the creating application used as part of the ingest process. For example, an HTML file was created pre-ingest using Dreamweaver, and the Web crawler Heritrix then captured a snapshot of the files as part of the ingest.\nThe amount of information needed for creatingApplication given here is minimal. For more granularity, extensibility is provided.\nRather than having each repository record this locally, it would be preferable to have a registry of this information similar to format or environment registries.".freeze],
|
1118
1105
|
subClassOf: term(
|
1119
1106
|
type: "owl:Class".freeze,
|
1120
1107
|
unionOf: list(term(
|
@@ -1134,10 +1121,7 @@ Rather than having each repository record this locally, it would be preferable t
|
|
1134
1121
|
type: "owl:Class".freeze,
|
1135
1122
|
"vs:term_status": "stable".freeze
|
1136
1123
|
term :Dependency,
|
1137
|
-
comment: [
|
1138
|
-
This semantic unit does not include objects required by structural relationships, such as child content objects \(e.g., figures that are part of an article\), which are recorded under relationship with a relationshipType of “structural”.
|
1139
|
-
It is up to the repository to determine what constitutes a dependency in the context of the designated community.
|
1140
|
-
The objects noted may be internal or external to the preservation repository.).freeze],
|
1124
|
+
comment: ["Creation / Maintenance Notes: Recommended practice is for a repository to archive objects on which other objects depend. These may be sent by the submitter of the primary object, or they may in some cases be automatically obtained by the repository. For example, a markup file will often contain links to other objects it requires such as DTDs or XML Schema. If it does, these objects can often be identified by the link and downloaded by the repository.".freeze, "Definition: Information about a non-software component or associated file needed in order to use or render the representation or file, for example, a schema, a DTD, or an entity file declaration.".freeze, "Usage Notes: This semantic unit is for additional objects that are necessary to render a file or representation, not for required software or hardware. It may also be used for a non-executable component of the object, such as a font or style sheet. For things that the software requires, see swDependency.\nThis semantic unit does not include objects required by structural relationships, such as child content objects (e.g., figures that are part of an article), which are recorded under relationship with a relationshipType of “structural”.\nIt is up to the repository to determine what constitutes a dependency in the context of the designated community.\nThe objects noted may be internal or external to the preservation repository.".freeze],
|
1141
1125
|
subClassOf: term(
|
1142
1126
|
type: "owl:Class".freeze,
|
1143
1127
|
unionOf: list(term(
|
@@ -1153,9 +1137,7 @@ The objects noted may be internal or external to the preservation repository.).f
|
|
1153
1137
|
type: "owl:Class".freeze,
|
1154
1138
|
"vs:term_status": "stable".freeze
|
1155
1139
|
term :Environment,
|
1156
|
-
comment: [
|
1157
|
-
Rather than having each repository record this locally, it would be preferable to have a registry of environment information similar to proposed registries of format information.
|
1158
|
-
Repositories may choose to design mechanisms for inheritance, so that if the environment required for each file within a representation is identical to the environment recorded for the representation as a whole, it is not necessary to store this information in each file.).freeze, %(Definition: Hardware/software combinations supporting use of the object.).freeze, %(Rationale: Environment is the means by which the user renders and interacts with content. Separation of digital content from its environmental context can result in the content becoming unusable.).freeze, %(Usage Notes: All of this semantic units’ subunits are optional. At least one subunit \(i.e. environmentNote, dependency, software, hardware, and/or environmentExtension\) must be present if this container is included.).freeze],
|
1140
|
+
comment: ["Creation / Maintenance Notes: This information may be omitted when the repository is doing only bit-level preservation on the object.\nRather than having each repository record this locally, it would be preferable to have a registry of environment information similar to proposed registries of format information.\nRepositories may choose to design mechanisms for inheritance, so that if the environment required for each file within a representation is identical to the environment recorded for the representation as a whole, it is not necessary to store this information in each file.".freeze, "Definition: Hardware/software combinations supporting use of the object.".freeze, "Rationale: Environment is the means by which the user renders and interacts with content. Separation of digital content from its environmental context can result in the content becoming unusable.".freeze, "Usage Notes: All of this semantic units’ subunits are optional. At least one subunit (i.e. environmentNote, dependency, software, hardware, and/or environmentExtension) must be present if this container is included.".freeze],
|
1159
1141
|
subClassOf: term(
|
1160
1142
|
maxCardinality: "1".freeze,
|
1161
1143
|
onProperty: "premis:hasEnvironmentCharacteristic".freeze,
|
@@ -1164,13 +1146,7 @@ Repositories may choose to design mechanisms for inheritance, so that if the env
|
|
1164
1146
|
type: "owl:Class".freeze,
|
1165
1147
|
"vs:term_status": "stable".freeze
|
1166
1148
|
term :Event,
|
1167
|
-
comment: [
|
1168
|
-
Must be related to one or more objects.
|
1169
|
-
Can be related to one or more agents.
|
1170
|
-
Links between entities may be recorded from either direction and need not be bi-directional.).freeze, %(The Event entity aggregates information about an action that involves one or more Object entities. Metadata about an Event would normally be recorded and stored separately from the digital object.
|
1171
|
-
Whether or not a preservation repository records an Event depends upon the importance of the event. Actions that modify objects should always be recorded. Other actions such as copying an object for backup purposes may be recorded in system logs or an audit trail but not necessarily in
|
1172
|
-
an Event entity.
|
1173
|
-
Mandatory semantic units are: eventIdentifier, eventType, and eventDateTime.).freeze],
|
1149
|
+
comment: ["Entity properties:\nMust be related to one or more objects.\nCan be related to one or more agents.\nLinks between entities may be recorded from either direction and need not be bi-directional.".freeze, "The Event entity aggregates information about an action that involves one or more Object entities. Metadata about an Event would normally be recorded and stored separately from the digital object.\nWhether or not a preservation repository records an Event depends upon the importance of the event. Actions that modify objects should always be recorded. Other actions such as copying an object for backup purposes may be recorded in system logs or an audit trail but not necessarily in\nan Event entity.\nMandatory semantic units are: eventIdentifier, eventType, and eventDateTime.".freeze],
|
1174
1150
|
subClassOf: ["premis:PremisEntity".freeze, term(
|
1175
1151
|
intersectionOf: list(term(
|
1176
1152
|
cardinality: "1".freeze,
|
@@ -1190,9 +1166,7 @@ Mandatory semantic units are: eventIdentifier, eventType, and eventDateTime.).fr
|
|
1190
1166
|
type: "owl:Class".freeze,
|
1191
1167
|
"vs:term_status": "stable".freeze
|
1192
1168
|
term :EventOutcomeDetail,
|
1193
|
-
comment: [
|
1194
|
-
If the event was a validity check \(e.g., profile conformance\) any anomalies or quirks discovered would be recorded here.
|
1195
|
-
All subunits of this semantic unit are optional. At least one subunit \(i.e. eventOutcomeDetailNote and/or eventOutcomeDetailExtension\) must be present if this container is included.).freeze],
|
1169
|
+
comment: ["Definition: A detailed description of the result or product of the event.".freeze, "Rationale: An event outcome may be sufficiently complex that a coded description is not adequate to document it.".freeze, "Usage Notes: This may be used to record all error and warning messages issued by a program involved in the event or to record a pointer to an error log.\nIf the event was a validity check (e.g., profile conformance) any anomalies or quirks discovered would be recorded here.\nAll subunits of this semantic unit are optional. At least one subunit (i.e. eventOutcomeDetailNote and/or eventOutcomeDetailExtension) must be present if this container is included.".freeze],
|
1196
1170
|
subClassOf: term(
|
1197
1171
|
maxCardinality: "1".freeze,
|
1198
1172
|
onProperty: "premis:hasEventOutcomeDetailNote".freeze,
|
@@ -1201,8 +1175,7 @@ All subunits of this semantic unit are optional. At least one subunit \(i.e. eve
|
|
1201
1175
|
type: "owl:Class".freeze,
|
1202
1176
|
"vs:term_status": "stable".freeze
|
1203
1177
|
term :EventOutcomeInformation,
|
1204
|
-
comment: [
|
1205
|
-
All subunits of this semantic unit are optional. At least one subunit \(i.e. eventOutcome or eventOutcomeDetail\) must be present if this container is included.).freeze],
|
1178
|
+
comment: ["Definition: Information about the outcome of an event.".freeze, "Usage Notes: A repository may wish to supplement a coded eventOutcome value with additional information in eventOutcomeDetail. Since events may have more than one outcome, the container is repeatable.\nAll subunits of this semantic unit are optional. At least one subunit (i.e. eventOutcome or eventOutcomeDetail) must be present if this container is included.".freeze],
|
1206
1179
|
subClassOf: term(
|
1207
1180
|
maxCardinality: "1".freeze,
|
1208
1181
|
onProperty: "premis:hasEventOutcome".freeze,
|
@@ -1211,7 +1184,7 @@ All subunits of this semantic unit are optional. At least one subunit \(i.e. eve
|
|
1211
1184
|
type: "owl:Class".freeze,
|
1212
1185
|
"vs:term_status": "stable".freeze
|
1213
1186
|
term :File,
|
1214
|
-
comment:
|
1187
|
+
comment: "Definition: A named and ordered sequence of bytes that is known to an operating system.".freeze,
|
1215
1188
|
"rdfs:seeAlso": "Object class definition".freeze,
|
1216
1189
|
subClassOf: ["premis:Object".freeze, term(
|
1217
1190
|
minCardinality: "1".freeze,
|
@@ -1221,10 +1194,7 @@ All subunits of this semantic unit are optional. At least one subunit \(i.e. eve
|
|
1221
1194
|
type: "owl:Class".freeze,
|
1222
1195
|
"vs:term_status": "stable".freeze
|
1223
1196
|
term :Fixity,
|
1224
|
-
comment: [
|
1225
|
-
The act of performing a fixity check and the date it occurred would be recorded as an Event. The result of the check would be recorded as the eventOutcome. Therefore, only the messageDigestAlgorithm and messageDigest need to be recorded as objectCharacteristics for future comparison.
|
1226
|
-
Representation level: It could be argued that if a representation consists of a single file or if all the files comprised by a representation are combined \(e.g., zipped\) into a single file, then a fixity check could be performed on the representation. However, in both cases the fixity check is actually being performed on a file, which in this case happens to be coincidental with a representation.
|
1227
|
-
Bitstream level: Message digests can be computed for bitstreams although they are not as common as with files. For example, the JPX format, which is a JPEG2000 format, supports the inclusion of MD5 or SHA-1 message digests in internal metadata that was calculated on any range of bytes of the file.).freeze],
|
1197
|
+
comment: ["Creation / Maintenance Notes: Automatically calculated and recorded by repository.".freeze, "Definition: Information used to verify whether an object has been altered in an undocumented or unauthorized way.".freeze, "Usage Notes: To perform a fixity check, a message digest calculated at some earlier time is compared with a message digest calculated at a later time. If the digests are the same, the object was not altered in the interim. Recommended practice is to use two or more message digests calculated by different algorithms. (Note that the terms “message digest” and “checksum” are commonly used interchangeably. However, the term “checksum” is more correctly used for the product of a cyclical redundancy check (CRC), whereas the term “message digest” refers to the result of a cryptographic hash function, which is what is referred to here.)\nThe act of performing a fixity check and the date it occurred would be recorded as an Event. The result of the check would be recorded as the eventOutcome. Therefore, only the messageDigestAlgorithm and messageDigest need to be recorded as objectCharacteristics for future comparison.\nRepresentation level: It could be argued that if a representation consists of a single file or if all the files comprised by a representation are combined (e.g., zipped) into a single file, then a fixity check could be performed on the representation. However, in both cases the fixity check is actually being performed on a file, which in this case happens to be coincidental with a representation.\nBitstream level: Message digests can be computed for bitstreams although they are not as common as with files. For example, the JPX format, which is a JPEG2000 format, supports the inclusion of MD5 or SHA-1 message digests in internal metadata that was calculated on any range of bytes of the file.".freeze],
|
1228
1198
|
subClassOf: term(
|
1229
1199
|
intersectionOf: list(term(
|
1230
1200
|
cardinality: "1".freeze,
|
@@ -1240,8 +1210,7 @@ Bitstream level: Message digests can be computed for bitstreams although they ar
|
|
1240
1210
|
type: "owl:Class".freeze,
|
1241
1211
|
"vs:term_status": "stable".freeze
|
1242
1212
|
term :Format,
|
1243
|
-
comment: [
|
1244
|
-
Although this semantic unit is mandatory, both of its subunits are optional. At least one subunit \(i.e. either formatDesignation or formatRegistry\) must be present if this container is included or both may be used. If the subunit \(formatDesignation or formatRegistry\) needs to be repeated, the entire format container is repeated. This allows for association of format designation with a particular set of format registry information. For example, if the precise format cannot be determined and two format designations are recorded, each is given within a separate format container. The format container may also be repeated for multiple format registry entries.).freeze],
|
1213
|
+
comment: ["Creation / Maintenance Notes: The format of a file or bitstream should be ascertained by the repository on ingest. Even if this information is provided by the submitter, directly in metadata or indirectly via the file name extension, recommended practice is to independently identify the format by parsing the file when possible. If the format cannot be identified at the time of ingest, it is valid to record that it is unknown, but the repository should subsequently make an effort to identify the format, even if manual intervention is required.".freeze, "Definition: Identification of the format of a file or bitstream where format is the organization of digital information according to preset specifications.".freeze, "Rationale: Many preservation activities depend on detailed knowledge about the format of the digital object. An accurate identification of format is essential. The identification provided, whether by name or pointer into a format registry, should be sufficient to associate the object with more detailed format information.".freeze, "Usage Notes: A bitstream embedded within a file may have different characteristics than the larger file. For example, a bitstream in LaTex format could be embedded within an SGML file, or multiple images using different colorspaces could be embedded within a TIFF file. format must be recorded for every object. When the bitstream format can be recognized by the repository and the repository might want to treat the bitstream differently from the embedding file for preservation purposes, format can be recorded for embedded bitstreams.\nAlthough this semantic unit is mandatory, both of its subunits are optional. At least one subunit (i.e. either formatDesignation or formatRegistry) must be present if this container is included or both may be used. If the subunit (formatDesignation or formatRegistry) needs to be repeated, the entire format container is repeated. This allows for association of format designation with a particular set of format registry information. For example, if the precise format cannot be determined and two format designations are recorded, each is given within a separate format container. The format container may also be repeated for multiple format registry entries.".freeze],
|
1245
1214
|
subClassOf: term(
|
1246
1215
|
type: "owl:Class".freeze,
|
1247
1216
|
unionOf: list(term(
|
@@ -1257,8 +1226,7 @@ Although this semantic unit is mandatory, both of its subunits are optional. At
|
|
1257
1226
|
type: "owl:Class".freeze,
|
1258
1227
|
"vs:term_status": "stable".freeze
|
1259
1228
|
term :FormatDesignation,
|
1260
|
-
comment: [
|
1261
|
-
The most specific format \(or format profile\) should be recorded. A repository \(or formats registry\) may wish to use multipart format names \(e.g., “TIFF_GeoTIFF” or “WAVE_MPEG_BWF”\) to achieve this specificity.).freeze],
|
1229
|
+
comment: ["Definition: An identification of the format of the object.".freeze, "Usage Notes: Either formatDesignation or at least one instance of formatRegistry is required. Both may be included.\nThe most specific format (or format profile) should be recorded. A repository (or formats registry) may wish to use multipart format names (e.g., “TIFF_GeoTIFF” or “WAVE_MPEG_BWF”) to achieve this specificity.".freeze],
|
1262
1230
|
subClassOf: term(
|
1263
1231
|
cardinality: "1".freeze,
|
1264
1232
|
onProperty: "premis:hasFormatName".freeze,
|
@@ -1267,8 +1235,7 @@ The most specific format \(or format profile\) should be recorded. A repository
|
|
1267
1235
|
type: "owl:Class".freeze,
|
1268
1236
|
"vs:term_status": "stable".freeze
|
1269
1237
|
term :FormatRegistry,
|
1270
|
-
comment: [
|
1271
|
-
The PREMIS working group assumed that a number of format registries will be developed and maintained to support digital preservation efforts. The proposal for a Global Digital Format Registry \(GDFR\) \(http://hul.harvard.edu/gdfr/documents.html#data\), for example, would create a network-accessible registry designed to store detailed specifications on formats and profiles.).freeze],
|
1238
|
+
comment: ["Definition: Identifies and/or gives further information about the format by reference to an entry in a format registry.".freeze, "Rationale: If central format registries are available to the preservation repository, they may provide an excellent way of referencing detailed format information.".freeze, "Usage Notes: Either formatDesignation or at least one instance of formatRegistry is required. If more than one formatRegistry needs to be recorded the format container should be repeated to include each additional set of formatRegistry information.\nThe PREMIS working group assumed that a number of format registries will be developed and maintained to support digital preservation efforts. The proposal for a Global Digital Format Registry (GDFR) (http://hul.harvard.edu/gdfr/documents.html#data), for example, would create a network-accessible registry designed to store detailed specifications on formats and profiles.".freeze],
|
1272
1239
|
subClassOf: [term(
|
1273
1240
|
cardinality: "1".freeze,
|
1274
1241
|
onProperty: "premis:hasFormatRegistryKey".freeze,
|
@@ -1281,8 +1248,7 @@ The PREMIS working group assumed that a number of format registries will be deve
|
|
1281
1248
|
type: "owl:Class".freeze,
|
1282
1249
|
"vs:term_status": "stable".freeze
|
1283
1250
|
term :Hardware,
|
1284
|
-
comment: [
|
1285
|
-
Because of the difficulty recording this information comprehensively, it would be optimal if central registries of environment information existed. In many cases the environment of a file object is directly associated with the format, making registry lookup by format feasible. In the absence of a global mechanism, repositories may be forced to develop their own local “registries” relating format to hwEnvironment.).freeze, %(Definition: Hardware components needed by the software referenced in swName or the human user of the referenced software.).freeze],
|
1251
|
+
comment: ["Creation / Maintenance Notes: Hardware environment information can be very difficult to provide. Many different hardware environments may apply; there are a huge number of combinations of maker and type of CPU, memory, video drivers, and so on. Although at least one hardware environment should be recorded, it is not necessary to record them all and each repository will have to make its own decisions about which hardware environments to record.\nBecause of the difficulty recording this information comprehensively, it would be optimal if central registries of environment information existed. In many cases the environment of a file object is directly associated with the format, making registry lookup by format feasible. In the absence of a global mechanism, repositories may be forced to develop their own local “registries” relating format to hwEnvironment.".freeze, "Definition: Hardware components needed by the software referenced in swName or the human user of the referenced software.".freeze],
|
1286
1252
|
subClassOf: term(
|
1287
1253
|
intersectionOf: list(term(
|
1288
1254
|
cardinality: "1".freeze,
|
@@ -1298,7 +1264,7 @@ Because of the difficulty recording this information comprehensively, it would b
|
|
1298
1264
|
type: "owl:Class".freeze,
|
1299
1265
|
"vs:term_status": "stable".freeze
|
1300
1266
|
term :Identifier,
|
1301
|
-
comment:
|
1267
|
+
comment: "This class is used in PREMIS OWL to describe identifiers if the identifiers are not http URIs.".freeze,
|
1302
1268
|
subClassOf: [term(
|
1303
1269
|
cardinality: "1".freeze,
|
1304
1270
|
onProperty: "premis:hasIdentifierType".freeze,
|
@@ -1311,9 +1277,7 @@ Because of the difficulty recording this information comprehensively, it would b
|
|
1311
1277
|
type: "owl:Class".freeze,
|
1312
1278
|
"vs:term_status": "stable".freeze
|
1313
1279
|
term :Inhibitors,
|
1314
|
-
comment: [
|
1315
|
-
Some file formats such as PDF use passwords to control access to content or specific functions. Although this is actually implemented at the bitstream level, for preservation purposes it is effectively managed at the file level; that is, passwords would not be recorded for individually addressable bitstreams.
|
1316
|
-
For certain types of inhibitor keys, more granularity may be required. If the inhibitor key information is identical to key information in digital signatures, use those semantic units.).freeze],
|
1280
|
+
comment: ["Creation / Maintenance Notes: Inhibitors are more likely to be present on an object ingested by the repository than applied by the repository itself. It is often not possible to tell that a file has been encrypted by parsing it; the file may appear to be ASCII text. Therefore, information about inhibitors should be supplied as metadata with submitted objects when possible.".freeze, "Definition: Features of the object intended to inhibit access, use, or migration.".freeze, "Rationale: Format information may indicate whether a file is encrypted, but the nature of the encryption also must be recorded, as well as the access key.".freeze, "Usage Notes: Some file formats allow encryption for embedded bitstreams.\nSome file formats such as PDF use passwords to control access to content or specific functions. Although this is actually implemented at the bitstream level, for preservation purposes it is effectively managed at the file level; that is, passwords would not be recorded for individually addressable bitstreams.\nFor certain types of inhibitor keys, more granularity may be required. If the inhibitor key information is identical to key information in digital signatures, use those semantic units.".freeze],
|
1317
1281
|
subClassOf: term(
|
1318
1282
|
cardinality: "1".freeze,
|
1319
1283
|
onProperty: "premis:hasInhibitorType".freeze,
|
@@ -1322,12 +1286,12 @@ For certain types of inhibitor keys, more granularity may be required. If the in
|
|
1322
1286
|
type: "owl:Class".freeze,
|
1323
1287
|
"vs:term_status": "stable".freeze
|
1324
1288
|
term :IntellectualEntity,
|
1325
|
-
comment: [
|
1289
|
+
comment: ["Definition: a set of content that is considered a single intellectual unit for purposes of management and description: for example, a particular book, map, photograph, or database. An Intellectual Entity can include other Intellectual Entities; for example, a Web site can include a Web page; a Web page can include an image. An Intellectual Entity may have one or more digital representations.".freeze, "Intellectual entities are described via Descriptive metadata models. These are very domain-specific and are out of scope for PREMIS. Examples: Dublin Core, Mets, MARC".freeze],
|
1326
1290
|
subClassOf: "premis:PremisEntity".freeze,
|
1327
1291
|
type: "owl:Class".freeze,
|
1328
1292
|
"vs:term_status": "stable".freeze
|
1329
1293
|
term :LicenseInformation,
|
1330
|
-
comment: [
|
1294
|
+
comment: ["Definition: Information about a license or other agreement granting permissions related to an object.".freeze, "Usage Note: When rights basis is a license, licenseInformation should be provided.".freeze],
|
1331
1295
|
subClassOf: ["premis:RightsStatement".freeze, term(
|
1332
1296
|
maxCardinality: "1".freeze,
|
1333
1297
|
onProperty: "premis:hasLicenseTerms".freeze,
|
@@ -1336,22 +1300,12 @@ For certain types of inhibitor keys, more granularity may be required. If the in
|
|
1336
1300
|
type: "owl:Class".freeze,
|
1337
1301
|
"vs:term_status": "stable".freeze
|
1338
1302
|
term :Object,
|
1339
|
-
comment: [
|
1340
|
-
Can be associated with one or more rights statements.
|
1341
|
-
Can participate in one or more events.
|
1342
|
-
Links between entities may be recorded from either direction and need not be bi-directional.).freeze, %(Entity types:
|
1343
|
-
Representation: A digital object instantiating or embodying an Intellectual Entity. A representation is the set of stored digital files and structural metadata needed to provide a complete and reasonable rendition of the Intellectual Entity.
|
1344
|
-
File: A named and ordered sequence of bytes that is known to an operating system.
|
1345
|
-
Bitstream: Contiguous or non-contiguous data within a file that has meaningful properties for preservation purposes.).freeze, %(The object class aggregates information about a digital object held by a preservation repository and describes those characteristics relevant to preservation management. The only mandatory property is objectIdentifier.
|
1346
|
-
The object class has three subclasses: Representation, File, and Bitstream.).freeze],
|
1303
|
+
comment: ["Entity properties:\nCan be associated with one or more rights statements.\nCan participate in one or more events.\nLinks between entities may be recorded from either direction and need not be bi-directional.".freeze, "Entity types: \nRepresentation: A digital object instantiating or embodying an Intellectual Entity. A representation is the set of stored digital files and structural metadata needed to provide a complete and reasonable rendition of the Intellectual Entity.\nFile: A named and ordered sequence of bytes that is known to an operating system.\nBitstream: Contiguous or non-contiguous data within a file that has meaningful properties for preservation purposes.".freeze, "The object class aggregates information about a digital object held by a preservation repository and describes those characteristics relevant to preservation management. The only mandatory property is objectIdentifier.\nThe object class has three subclasses: Representation, File, and Bitstream.".freeze],
|
1347
1304
|
subClassOf: "premis:PremisEntity".freeze,
|
1348
1305
|
type: "owl:Class".freeze,
|
1349
1306
|
"vs:term_status": "stable".freeze
|
1350
1307
|
term :ObjectCharacteristics,
|
1351
|
-
comment: [
|
1352
|
-
When encryption is applied, the objectCharacteristics block must include an inhibitors semantic unit.
|
1353
|
-
A bitstream embedded within a file may have different object characteristics than the file. Where these characteristics are relevant for preservation, they should be recorded.
|
1354
|
-
When a single file is equivalent to a representation, objectCharacteristics may be applied and thus associated with the representation. In these cases, the relationship between the file comprising the representation and other associated files may be expressed using relationshipSubType.).freeze],
|
1308
|
+
comment: ["Definition: Technical properties of a file or bitstream that are applicable to all or most formats.".freeze, "Rationale: There are some important technical properties that apply to objects of any format. Detailed definition of format-specific properties is outside the scope of this Data Dictionary, although such properties may be included within objectCharacteristicsExtension.".freeze, "Usage Notes: The semantic units included in objectCharacteristics should be treated as a set of information that pertains to a single object at a single compositionLevel. Object characteristics may be repeated when an object was created by applying two or more encodings, such as compression and encryption. In this case each repetition of objectCharacteristics would have an incrementally higher compositionLevel.\nWhen encryption is applied, the objectCharacteristics block must include an inhibitors semantic unit.\nA bitstream embedded within a file may have different object characteristics than the file. Where these characteristics are relevant for preservation, they should be recorded.\nWhen a single file is equivalent to a representation, objectCharacteristics may be applied and thus associated with the representation. In these cases, the relationship between the file comprising the representation and other associated files may be expressed using relationshipSubType.".freeze],
|
1355
1309
|
subClassOf: [term(
|
1356
1310
|
cardinality: "1".freeze,
|
1357
1311
|
onProperty: "premis:hasCompositionLevel".freeze,
|
@@ -1364,15 +1318,13 @@ When a single file is equivalent to a representation, objectCharacteristics may
|
|
1364
1318
|
type: "owl:Class".freeze,
|
1365
1319
|
"vs:term_status": "stable".freeze
|
1366
1320
|
term :PremisEntity,
|
1367
|
-
comment:
|
1321
|
+
comment: "Definition: Basicly, the preservation information in PREMIS OWL consists of five entities related to each other. The entities are: Agent, Event, IntellectualEntity, Object, and RightsStatement.".freeze,
|
1368
1322
|
"owl:versionInfo": "PREMIS 2.2 Owl v2".freeze,
|
1369
1323
|
subClassOf: "owl:Thing".freeze,
|
1370
1324
|
type: "owl:Class".freeze,
|
1371
1325
|
"vs:term_status": "stable".freeze
|
1372
1326
|
term :PreservationLevel,
|
1373
|
-
comment: [
|
1374
|
-
Application of a particular set of preservationLevel semantic units may only cover a single representation of an object: representations in other technical forms or serving other functions may have a different preservationLevel applied.
|
1375
|
-
The container may be repeated if a preservation level value needs to be recorded in additional contexts \(see preservationLevelRole\).).freeze],
|
1327
|
+
comment: ["Creation / Maintenance Notes: The preservation level may be assigned by the repository or requested by the depositor and submitted as metadata. The repository may also choose to record additional metadata indicating the context for the assignment of the preservation level.".freeze, "Definition: Information indicating the decision or policy on the set of preservation functions to be applied to an object and the context in which the decision or policy was made.".freeze, "Rationale: Some preservation repositories will offer multiple preservation options depending on factors such as the value or uniqueness of the material, the “preservability” of the format, the amount the customer is willing to pay, etc. The context surrounding the choice of a particular preservation option for an object may also require further explanation.".freeze, "Usage Notes: If the repository offers only a single preservation level, this value does not need to be explicitly recorded within the repository.\nApplication of a particular set of preservationLevel semantic units may only cover a single representation of an object: representations in other technical forms or serving other functions may have a different preservationLevel applied.\nThe container may be repeated if a preservation level value needs to be recorded in additional contexts (see preservationLevelRole).".freeze],
|
1376
1328
|
subClassOf: [term(
|
1377
1329
|
cardinality: "1".freeze,
|
1378
1330
|
onProperty: "premis:hasPreservationLevelValue".freeze,
|
@@ -1385,7 +1337,7 @@ The container may be repeated if a preservation level value needs to be recorded
|
|
1385
1337
|
type: "owl:Class".freeze,
|
1386
1338
|
"vs:term_status": "stable".freeze
|
1387
1339
|
term :RelatedObjectIdentification,
|
1388
|
-
comment: [
|
1340
|
+
comment: [" Definition: The identifier and sequential context of the related resource".freeze, "Usage Notes: The related object may or may not be held within the preservation repository. Recommended practice is that objects reside within the repository unless there is a good reason to reference an object outside. Internal and external references should be clear.".freeze],
|
1389
1341
|
subClassOf: term(
|
1390
1342
|
intersectionOf: list(term(
|
1391
1343
|
cardinality: "1".freeze,
|
@@ -1401,14 +1353,13 @@ The container may be repeated if a preservation level value needs to be recorded
|
|
1401
1353
|
type: "owl:Class".freeze,
|
1402
1354
|
"vs:term_status": "stable".freeze
|
1403
1355
|
term :Representation,
|
1404
|
-
comment:
|
1356
|
+
comment: "Definition: A digital object instantiating or embodying an Intellectual Entity. A representation is the set of stored digital files and structural metadata needed to provide a complete and reasonable rendition of the Intellectual Entity.".freeze,
|
1405
1357
|
"rdfs:seeAlso": "Object class definition".freeze,
|
1406
1358
|
subClassOf: "premis:Object".freeze,
|
1407
1359
|
type: "owl:Class".freeze,
|
1408
1360
|
"vs:term_status": "stable".freeze
|
1409
1361
|
term :RightsDocumentation,
|
1410
|
-
comment:
|
1411
|
-
specified rights within the repository system.).freeze,
|
1362
|
+
comment: "Definition: A designation used to uniquely identify documentation supporting the\nspecified rights within the repository system.".freeze,
|
1412
1363
|
subClassOf: term(
|
1413
1364
|
maxCardinality: "1".freeze,
|
1414
1365
|
onProperty: "premis:hasRightsDocumentationRole".freeze,
|
@@ -1417,7 +1368,7 @@ specified rights within the repository system.).freeze,
|
|
1417
1368
|
type: "owl:Class".freeze,
|
1418
1369
|
"vs:term_status": "stable".freeze
|
1419
1370
|
term :RightsGranted,
|
1420
|
-
comment:
|
1371
|
+
comment: "Definition: The action(s) that the granting agency has allowed the repository.".freeze,
|
1421
1372
|
subClassOf: [term(
|
1422
1373
|
intersectionOf: list(term(
|
1423
1374
|
cardinality: "1".freeze,
|
@@ -1437,9 +1388,7 @@ specified rights within the repository system.).freeze,
|
|
1437
1388
|
type: "owl:Class".freeze,
|
1438
1389
|
"vs:term_status": "stable".freeze
|
1439
1390
|
term :RightsStatement,
|
1440
|
-
comment: [
|
1441
|
-
Either rightsStatement or rightsExtension must be present if the Rights entity is included.
|
1442
|
-
The rightsStatement should be repeated when the act\(s\) described has more than one basis, or when different acts have different bases.).freeze],
|
1391
|
+
comment: ["Definition: Documentation of the repository's right to perform one or more acts.".freeze, "Extensions: In OWL one can define its own subclasses to the the RightsStatement class to denote OtherRightsInformation of the PREMIS data dictionary.".freeze, "Usage Notes: This semantic unit is optional because in some cases rights may be unknown. Institutions are encouraged to record rights information when possible.\nEither rightsStatement or rightsExtension must be present if the Rights entity is included.\nThe rightsStatement should be repeated when the act(s) described has more than one basis, or when different acts have different bases.".freeze],
|
1443
1392
|
subClassOf: ["dc:RightsStatement".freeze, "premis:PremisEntity".freeze, term(
|
1444
1393
|
maxCardinality: "1".freeze,
|
1445
1394
|
onProperty: "premis:hasApplicableDates".freeze,
|
@@ -1452,7 +1401,7 @@ The rightsStatement should be repeated when the act\(s\) described has more than
|
|
1452
1401
|
type: "owl:Class".freeze,
|
1453
1402
|
"vs:term_status": "stable".freeze
|
1454
1403
|
term :Signature,
|
1455
|
-
comment: [
|
1404
|
+
comment: ["Definition: Information needed to use a digital signature to authenticate the signer of an object and/or the information contained in the object.".freeze, "Rationale: A repository may have a policy of generating digital signatures for files on ingest, or may have a need to store and later validate incoming digital signatures.".freeze, "Usage Notes: Several of the semantic components of signatureInformation are taken from the W3C’s XML-Signature Syntax and Processing; see www.w3.org/TR/2002/REC-xmldsig-core-20020212/ for more information on the structure and application of these semantic units.".freeze],
|
1456
1405
|
subClassOf: term(
|
1457
1406
|
intersectionOf: list(term(
|
1458
1407
|
cardinality: "1".freeze,
|
@@ -1476,31 +1425,11 @@ The rightsStatement should be repeated when the act\(s\) described has more than
|
|
1476
1425
|
type: "owl:Class".freeze,
|
1477
1426
|
"vs:term_status": "stable".freeze
|
1478
1427
|
term :SignificantProperties,
|
1479
|
-
comment: [
|
1480
|
-
Significant properties may be objective technical characteristics subjectively considered important, or subjectively determined characteristics. For example, a PDF may contain links that are not considered important and JavaScript that is considered important. Or future migrations of a TIFF image may require optimization for line clarity or for color; the option chosen would depend upon a curatorial judgment of the significant properties of the image.
|
1481
|
-
Listing significant properties implies that the repository plans to preserve these properties across time and requires them to acceptably survive preservation action; for example, to be maintained during emulation or after format migration. It also implies that the repository would note when preservation action results in modification of significant properties.
|
1482
|
-
In practice, significant properties might be used as measures of preservation success, as part of quality checking the results of a preservation action or evaluating the efficacy of a preservation method. For example, if the listed significant properties are not maintained after application of a particular preservation method, it may indicate a failure of the process or that the method is not well suited to the type of material.
|
1483
|
-
More experience with digital preservation is needed to determine the best ways of representing significant properties in general, and of representing modification of significant properties.
|
1484
|
-
The semantic units included in the significantProperties container aim to provide a flexible structure for describing significant properties, allowing general types of aspects, facets or attributes of an object to be declared and to be paired with specific significant details about the object pertaining to that aspect, facet or attribute.
|
1485
|
-
For example, some repositories may define significant properties for objects related to facets of content, appearance, structure, behavior, and context. Examples of facet:detail pairs in this case could include:
|
1486
|
-
significantPropertiesType = “content”
|
1487
|
-
significantPropertiesValue = “all textual content and images”
|
1488
|
-
significantPropertiesType = “behavior”
|
1489
|
-
significantPropertiesValue = “editable”
|
1490
|
-
Other repositories may choose to describe significant properties at a more granular attribute level; for example:
|
1491
|
-
significantPropertiesType = “page count”
|
1492
|
-
significantPropertiesValue = “7”
|
1493
|
-
significantPropertiesType = “page width”
|
1494
|
-
significantPropertiesValue = “210 mm”
|
1495
|
-
Each facet:detail pair should be contained in a separate, repeated significantProperties container.
|
1496
|
-
Further work on determining and describing significant properties may yield more detailed schemes to facilitate general description.
|
1497
|
-
Representing modification of significant properties as a result of preservation action also requires further work. One possible way involves the use of Object and Event information: Object A has significant properties volume and timing, which are recorded as significantProperties of A. In migrated version B, the timing is modified, which is noted in the eventOutcome of the migration event. Only volume is listed as a significant property of B.).freeze],
|
1428
|
+
comment: ["Creation / Maintenance Notes: Significant properties may pertain to all objects of a certain class; for example, the repository can decide that for all PDF files, only the content need be preserved. In other cases, for example, for media art, the significant properties may be unique to each individual object. Where values are unique, they must be supplied by the submitter or provided by the curatorial staff of the repository.".freeze, "Definition: Characteristics of a particular object subjectively determined to be important to maintain through preservation actions.".freeze, "Rationale: Objects that have the same technical properties may still differ as to the properties that should be preserved for future presentation or use.".freeze, "Usage Notes: All of this semantic unit’s subunits are optional. At least one of the significantPropertiesValue and significantPropertiesExtension subunits must be present if this container is included or both may be used.\nSignificant properties may be objective technical characteristics subjectively considered important, or subjectively determined characteristics. For example, a PDF may contain links that are not considered important and JavaScript that is considered important. Or future migrations of a TIFF image may require optimization for line clarity or for color; the option chosen would depend upon a curatorial judgment of the significant properties of the image.\nListing significant properties implies that the repository plans to preserve these properties across time and requires them to acceptably survive preservation action; for example, to be maintained during emulation or after format migration. It also implies that the repository would note when preservation action results in modification of significant properties.\nIn practice, significant properties might be used as measures of preservation success, as part of quality checking the results of a preservation action or evaluating the efficacy of a preservation method. For example, if the listed significant properties are not maintained after application of a particular preservation method, it may indicate a failure of the process or that the method is not well suited to the type of material.\nMore experience with digital preservation is needed to determine the best ways of representing significant properties in general, and of representing modification of significant properties.\nThe semantic units included in the significantProperties container aim to provide a flexible structure for describing significant properties, allowing general types of aspects, facets or attributes of an object to be declared and to be paired with specific significant details about the object pertaining to that aspect, facet or attribute.\nFor example, some repositories may define significant properties for objects related to facets of content, appearance, structure, behavior, and context. Examples of facet:detail pairs in this case could include:\nsignificantPropertiesType = “content”\nsignificantPropertiesValue = “all textual content and images”\nsignificantPropertiesType = “behavior”\nsignificantPropertiesValue = “editable”\nOther repositories may choose to describe significant properties at a more granular attribute level; for example:\nsignificantPropertiesType = “page count”\nsignificantPropertiesValue = “7”\nsignificantPropertiesType = “page width”\nsignificantPropertiesValue = “210 mm”\nEach facet:detail pair should be contained in a separate, repeated significantProperties container.\nFurther work on determining and describing significant properties may yield more detailed schemes to facilitate general description.\nRepresenting modification of significant properties as a result of preservation action also requires further work. One possible way involves the use of Object and Event information: Object A has significant properties volume and timing, which are recorded as significantProperties of A. In migrated version B, the timing is modified, which is noted in the eventOutcome of the migration event. Only volume is listed as a significant property of B.".freeze],
|
1498
1429
|
type: "owl:Class".freeze,
|
1499
1430
|
"vs:term_status": "stable".freeze
|
1500
1431
|
term :Software,
|
1501
|
-
comment: [
|
1502
|
-
Also, what appears to the user as a single rendering program can have many dependencies, including system utilities, runtime libraries, and so on, which each might have their own dependencies in turn.
|
1503
|
-
As with environment, metadata may be more efficiently managed in conjunction with a format registry either internal or external to a repository. In the absence of a global mechanism, repositories may be forced to develop their own local “registries” relating format to software environment.).freeze, %(Definition: Software required to render or use the object.).freeze],
|
1432
|
+
comment: ["Creation / Maintenance Notes: If recording this explicitly, many different software environments may apply; for example, a particular object such as a PDF file may be viewable by several versions of several applications running under several operating systems and operating system versions. Although at least one software environment should be recorded, it is not necessary to record them all and each repository will have to make its own decisions about which software environments to record.\nAlso, what appears to the user as a single rendering program can have many dependencies, including system utilities, runtime libraries, and so on, which each might have their own dependencies in turn.\nAs with environment, metadata may be more efficiently managed in conjunction with a format registry either internal or external to a repository. In the absence of a global mechanism, repositories may be forced to develop their own local “registries” relating format to software environment.".freeze, "Definition: Software required to render or use the object.".freeze],
|
1504
1433
|
subClassOf: term(
|
1505
1434
|
intersectionOf: list(term(
|
1506
1435
|
cardinality: "1".freeze,
|
@@ -1516,7 +1445,7 @@ As with environment, metadata may be more efficiently managed in conjunction wit
|
|
1516
1445
|
type: "owl:Class".freeze,
|
1517
1446
|
"vs:term_status": "stable".freeze
|
1518
1447
|
term :StatuteInformation,
|
1519
|
-
comment: [
|
1448
|
+
comment: ["Definition: Information about the statute allowing use of the object.".freeze, "Usage Notes: When rights basis is a statute, statuteInformation should be provided.".freeze],
|
1520
1449
|
subClassOf: ["premis:RightsStatement".freeze, term(
|
1521
1450
|
intersectionOf: list(term(
|
1522
1451
|
cardinality: "1".freeze,
|
@@ -1532,8 +1461,7 @@ As with environment, metadata may be more efficiently managed in conjunction wit
|
|
1532
1461
|
type: "owl:Class".freeze,
|
1533
1462
|
"vs:term_status": "stable".freeze
|
1534
1463
|
term :Storage,
|
1535
|
-
comment: [
|
1536
|
-
Although this semantic unit is mandatory, both of its subunits are optional. At least one subunit \(i.e. either contentLocation or storageMedium\) must be present or both may be used.).freeze],
|
1464
|
+
comment: ["Definition: Information about how and where a file is stored in the storage system.".freeze, "Rationale: It is necessary for a repository to associate the contentLocation with the storageMedium.".freeze, "Usage Notes: Normally there would be a single storage location and medium for an object, because an object in another location would be considered a different object. The storage composite should be repeated if there are two or more copies that are identical bit-wise and managed as a unit except for the medium on which they are stored. They must have a single objectIdentifier and be managed as a single object by the repository.\nAlthough this semantic unit is mandatory, both of its subunits are optional. At least one subunit (i.e. either contentLocation or storageMedium) must be present or both may be used.".freeze],
|
1537
1465
|
subClassOf: term(
|
1538
1466
|
type: "owl:Class".freeze,
|
1539
1467
|
unionOf: list(term(
|
@@ -1549,7 +1477,7 @@ Although this semantic unit is mandatory, both of its subunits are optional. At
|
|
1549
1477
|
type: "owl:Class".freeze,
|
1550
1478
|
"vs:term_status": "stable".freeze
|
1551
1479
|
term :TermOfGrant,
|
1552
|
-
comment: [
|
1480
|
+
comment: ["Definition: The time period for the permissions granted.".freeze, "Rationale: The permission to preserve may be time bounded.".freeze],
|
1553
1481
|
subClassOf: ["premis:ApplicableDates".freeze, term(
|
1554
1482
|
cardinality: "1".freeze,
|
1555
1483
|
onProperty: "premis:hasStartDate".freeze,
|
@@ -1558,7 +1486,7 @@ Although this semantic unit is mandatory, both of its subunits are optional. At
|
|
1558
1486
|
type: "owl:Class".freeze,
|
1559
1487
|
"vs:term_status": "stable".freeze
|
1560
1488
|
term :TermOfRestriction,
|
1561
|
-
comment: [
|
1489
|
+
comment: ["Definition: The time period for the restriction granted.".freeze, "Rationale: The current definition of termOfGrant is \"time period for the permissions granted.\" This allows for expressing information about the rights granted, but some repositories may need to express timebounded restrictions like embargoes. If this is applicable startDate for the beginning of the embargo and endDate for the end of the embargo should be recorded.".freeze],
|
1562
1490
|
subClassOf: ["premis:ApplicableDates".freeze, term(
|
1563
1491
|
cardinality: "1".freeze,
|
1564
1492
|
onProperty: "premis:hasStartDate".freeze,
|
@@ -1569,7 +1497,7 @@ Although this semantic unit is mandatory, both of its subunits are optional. At
|
|
1569
1497
|
|
1570
1498
|
# Property definitions
|
1571
1499
|
property :hasAct,
|
1572
|
-
comment: [
|
1500
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/actionsGranted ".freeze, "Definition: The action the preservation repository is allowed to take.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze],
|
1573
1501
|
domain: "premis:RightsGranted".freeze,
|
1574
1502
|
range: term(
|
1575
1503
|
onProperty: "skos:inScheme".freeze,
|
@@ -1579,7 +1507,7 @@ Although this semantic unit is mandatory, both of its subunits are optional. At
|
|
1579
1507
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1580
1508
|
"vs:term_status": "stable".freeze
|
1581
1509
|
property :hasAgent,
|
1582
|
-
comment: [
|
1510
|
+
comment: ["Definition: link to the associated Agent.".freeze, "Rationale: Digital provenance requires often that relationships between agents and events are documented. The role of the associated agent may need to be documented. For this, a SKOS vocabulary can be used. The LOC will publish a vocabulary at http://id.loc.gov/, denoting the agent's role. These vocabulary will publish the concepts also as subproperties to the linkingAgent property, for denoting the role of the agent in the event or rightsstatement.".freeze],
|
1583
1511
|
domain: term(
|
1584
1512
|
type: "owl:Class".freeze,
|
1585
1513
|
unionOf: list("premis:Event".freeze, "premis:RightsStatement".freeze)
|
@@ -1589,21 +1517,19 @@ Although this semantic unit is mandatory, both of its subunits are optional. At
|
|
1589
1517
|
type: "owl:ObjectProperty".freeze,
|
1590
1518
|
"vs:term_status": "testing".freeze
|
1591
1519
|
property :hasAgentName,
|
1592
|
-
comment: [
|
1520
|
+
comment: ["Definition: A text string which could be used in addition to agentIdentifier to identify an agent.".freeze, "Examples: Erik Owens, Pc".freeze, "Rationale: This semantic unit provides a more reader-friendly version of the agent identified by the agentIdentifier.".freeze, "Usage Note: The value is not necessarily unique.".freeze],
|
1593
1521
|
domain: "premis:Agent".freeze,
|
1594
1522
|
range: "xsd:string".freeze,
|
1595
1523
|
type: "owl:DatatypeProperty".freeze,
|
1596
1524
|
"vs:term_status": "stable".freeze
|
1597
1525
|
property :hasAgentNote,
|
1598
|
-
comment: [
|
1599
|
-
).freeze, %(Rationale: Additional information may be needed to describe or disambiguate
|
1600
|
-
the agent.).freeze],
|
1526
|
+
comment: ["Definition: Additional information about the agent.\n".freeze, "Rationale: Additional information may be needed to describe or disambiguate\nthe agent.".freeze],
|
1601
1527
|
domain: "premis:Agent".freeze,
|
1602
1528
|
range: "xsd:string".freeze,
|
1603
1529
|
type: "owl:DatatypeProperty".freeze,
|
1604
1530
|
"vs:term_status": "stable".freeze
|
1605
1531
|
property :hasAgentType,
|
1606
|
-
comment: [
|
1532
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/agentType ".freeze, "Definition: A high-level characterization of the type of agent.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze],
|
1607
1533
|
domain: "premis:Agent".freeze,
|
1608
1534
|
range: term(
|
1609
1535
|
onProperty: "skos:inScheme".freeze,
|
@@ -1619,10 +1545,7 @@ the agent.).freeze],
|
|
1619
1545
|
type: "owl:ObjectProperty".freeze,
|
1620
1546
|
"vs:term_status": "stable".freeze
|
1621
1547
|
property :hasCompositionLevel,
|
1622
|
-
comment: [
|
1623
|
-
Numbering goes lowest to highest \(first encoded = 0\). 0 is base object; 1-n are subsequent encodings.
|
1624
|
-
Use 0 as the default if there is only one compositionLevel.
|
1625
|
-
When multiple file objects are bundled together as filestreams within a package file object \(e.g., a ZIP file\), the individual filestream objects are not composition levels of the package file object. They should be considered separate objects, each with their own composition levels. For example, two encrypted files zipped together and stored in an archive as one file object would be described as three separate objects, each with its own associated metadata. The storage location of the two inner objects would point to the ZIP file, but the ZIP file itself would have only a single composition level \(of zero\) whose format would be “zip.”).freeze],
|
1548
|
+
comment: ["Creation / Maintenance Notes: Composition level will generally be supplied by the repository, which should attempt to supply this value automatically. If the object was created by the repository, the creating routine knows the composition level and can supply this metadata. If the object is being ingested by the repository, repository programs will have to attempt to identify the composition level from the object itself or from externally supplied metadata.".freeze, "Data Constraints: Non-negative integers.".freeze, "Definition: An indication of whether the object is subject to one or more processes of decoding or unbundling.".freeze, "Examples: 0, 1, 2".freeze, "Rationale: A file or bitstream can be encoded with compression, encryption, etc., or bundled with other files or bitstreams into larger packages. Knowing the order in which these actions are taken is important if the original object or objects must be recovered.".freeze, "Usage Notes: A file or bitstream can be subject to multiple encodings that must be decoded in reverse order (highest to lowest). For example, file A may be compressed to create file B, which is encrypted to create file C. To recreate a copy of the base file A, one would have to unencrypt file C to create file B and then uncompress file B to create file A. A compositionLevel of zero indicates that the object is a base object and not subject to further decoding, while a level of 1 or higher indicates that one or more decodings must be applied.\nNumbering goes lowest to highest (first encoded = 0). 0 is base object; 1-n are subsequent encodings.\nUse 0 as the default if there is only one compositionLevel.\nWhen multiple file objects are bundled together as filestreams within a package file object (e.g., a ZIP file), the individual filestream objects are not composition levels of the package file object. They should be considered separate objects, each with their own composition levels. For example, two encrypted files zipped together and stored in an archive as one file object would be described as three separate objects, each with its own associated metadata. The storage location of the two inner objects would point to the ZIP file, but the ZIP file itself would have only a single composition level (of zero) whose format would be “zip.”".freeze],
|
1626
1549
|
domain: "premis:ObjectCharacteristics".freeze,
|
1627
1550
|
range: "xsd:int".freeze,
|
1628
1551
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -1634,7 +1557,7 @@ When multiple file objects are bundled together as filestreams within a package
|
|
1634
1557
|
type: ["owl:FunctionalProperty".freeze, "owl:InverseFunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1635
1558
|
"vs:term_status": "stable".freeze
|
1636
1559
|
property :hasContentLocationType,
|
1637
|
-
comment: [
|
1560
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/contentLocationType".freeze, "Definition: The means of referencing the location of the content.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: To understand the meaning of the value it is necessary to know what location scheme is used.".freeze],
|
1638
1561
|
domain: "premis:ContentLocation".freeze,
|
1639
1562
|
range: term(
|
1640
1563
|
onProperty: "skos:inScheme".freeze,
|
@@ -1644,19 +1567,19 @@ When multiple file objects are bundled together as filestreams within a package
|
|
1644
1567
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1645
1568
|
"vs:term_status": "stable".freeze
|
1646
1569
|
property :hasContentLocationValue,
|
1647
|
-
comment: [
|
1570
|
+
comment: ["Definition: The reference to the location of the content used by the storage system.".freeze, "Examples: http://wwasearch.loc.gov/107th/200212107035/http://house.gov/langevin/ (file), c:\\apache2\\htdocs\\index.html (file), 64 [offset from start of file c:\\apache2\\htdocs\\image\\logo.gif] (bitstream)".freeze, "Usage Notes: This could be a fully qualified path and filename, or the information used by a resolution system (e.g., a handle) or the native information used by a storage management system. For a bitstream or filestream, this would probably be the reference point and offset of the starting position of the bitstream. It is up to the repository to determine the level of granularity that should be recorded.".freeze],
|
1648
1571
|
domain: "premis:ContentLocation".freeze,
|
1649
1572
|
range: "xsd:string".freeze,
|
1650
1573
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1651
1574
|
"vs:term_status": "stable".freeze
|
1652
1575
|
property :hasCopyrightJurisdiction,
|
1653
|
-
comment: [
|
1576
|
+
comment: ["Data Constraint: Values should be taken from ISO 3166.".freeze, "Definition: The country whose copyright laws apply.".freeze, "Examples: us, de, be".freeze, "Rationale: Copyright law can vary from country to country.".freeze],
|
1654
1577
|
domain: "premis:CopyrightInformation".freeze,
|
1655
1578
|
range: "xsd:string".freeze,
|
1656
1579
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1657
1580
|
"vs:term_status": "stable".freeze
|
1658
1581
|
property :hasCopyrightStatus,
|
1659
|
-
comment: [
|
1582
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/copyrightStatus".freeze, "Definition: A coded designation for the copyright status of the object at the time the rights statement is recorded.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze],
|
1660
1583
|
domain: "premis:CopyrightInformation".freeze,
|
1661
1584
|
range: term(
|
1662
1585
|
onProperty: "skos:inScheme".freeze,
|
@@ -1666,7 +1589,7 @@ When multiple file objects are bundled together as filestreams within a package
|
|
1666
1589
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1667
1590
|
"vs:term_status": "stable".freeze
|
1668
1591
|
property :hasCopyrightStatusDeterminationDate,
|
1669
|
-
comment: [
|
1592
|
+
comment: ["Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime".freeze, "Definition: The date that the copyright status recorded in copyrightStatus was determined.".freeze, "Example: 2001-10-26T19:32:52+00:00".freeze],
|
1670
1593
|
domain: "premis:CopyrightInformation".freeze,
|
1671
1594
|
range: "xsd:dateTime".freeze,
|
1672
1595
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -1678,22 +1601,19 @@ When multiple file objects are bundled together as filestreams within a package
|
|
1678
1601
|
type: "owl:ObjectProperty".freeze,
|
1679
1602
|
"vs:term_status": "stable".freeze
|
1680
1603
|
property :hasCreatingApplicationName,
|
1681
|
-
comment: [
|
1604
|
+
comment: ["Definition: A designation for the name of the software program that created the object.".freeze, "Example: MSWord".freeze, "Usage Notes: The creatingApplication is the application that created the object in its current format, not the application that created the copy written to storage. For example, if a document is created by Microsoft Word and subsequently copied to archive storage by a repository’s Ingest program, the creatingApplication is Word, not the Ingest program.".freeze],
|
1682
1605
|
domain: "premis:CreatingApplication".freeze,
|
1683
1606
|
range: "xsd:string".freeze,
|
1684
1607
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1685
1608
|
"vs:term_status": "stable".freeze
|
1686
1609
|
property :hasCreatingApplicationVersion,
|
1687
|
-
comment: [
|
1610
|
+
comment: ["Definition: The version of the software program that created the object.".freeze, "Example: 2000".freeze],
|
1688
1611
|
domain: "premis:CreatingApplication".freeze,
|
1689
1612
|
range: "xsd:string".freeze,
|
1690
1613
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1691
1614
|
"vs:term_status": "stable".freeze
|
1692
1615
|
property :hasDateCreatedByApplication,
|
1693
|
-
comment: [
|
1694
|
-
This is the date the object was created by the creating application, not the date any copy was made externally or by the repository. For example, if a file is created by Microsoft Word in 2001 and two copies are made in 2003, the dateCreatedByApplication of all three files is 2001. The date a file is written to storage can be recorded as an Event.
|
1695
|
-
If the object itself contains internal creation and modification dates, the modification date should be used as dateCreatedByApplication.
|
1696
|
-
If the application is a Web harvester capturing an object at a point of time, use for date captured.).freeze],
|
1616
|
+
comment: ["Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime".freeze, "Definition: The actual or approximate date and time the object was created.".freeze, "Example: 2001-10-26T19:32:52+00:00".freeze, "Usage Notes: Use the most precise date available.\nThis is the date the object was created by the creating application, not the date any copy was made externally or by the repository. For example, if a file is created by Microsoft Word in 2001 and two copies are made in 2003, the dateCreatedByApplication of all three files is 2001. The date a file is written to storage can be recorded as an Event.\nIf the object itself contains internal creation and modification dates, the modification date should be used as dateCreatedByApplication.\nIf the application is a Web harvester capturing an object at a point of time, use for date captured.".freeze],
|
1697
1617
|
domain: "premis:CreatingApplication".freeze,
|
1698
1618
|
range: "xsd:dateTime".freeze,
|
1699
1619
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -1705,13 +1625,13 @@ If the application is a Web harvester capturing an object at a point of time, us
|
|
1705
1625
|
type: "owl:ObjectProperty".freeze,
|
1706
1626
|
"vs:term_status": "stable".freeze
|
1707
1627
|
property :hasDependencyName,
|
1708
|
-
comment: [
|
1628
|
+
comment: ["Definition: A designation for a component or associated file needed by the representation or file.".freeze, "Example: Additional Element Set for Language Corpora".freeze, "Rationale: It may not be self-evident from the dependencyIdentifier what the name of the object actually is.".freeze],
|
1709
1629
|
domain: "premis:Dependency".freeze,
|
1710
1630
|
range: "xsd:string".freeze,
|
1711
1631
|
type: "owl:DatatypeProperty".freeze,
|
1712
1632
|
"vs:term_status": "stable".freeze
|
1713
1633
|
property :hasEndDate,
|
1714
|
-
comment: [
|
1634
|
+
comment: ["Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime".freeze, "Definition: The ending date of the permission granted.".freeze, "Usage Notes: Use “0000-00-00T00:00:00+00:00” for an open ended term of grant. Omit endDate if the ending date is unknown or the permission statement applies to many objects with different end dates.".freeze],
|
1715
1635
|
domain: "premis:ApplicableDates".freeze,
|
1716
1636
|
range: "xsd:dateTime".freeze,
|
1717
1637
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -1723,7 +1643,7 @@ If the application is a Web harvester capturing an object at a point of time, us
|
|
1723
1643
|
type: "owl:ObjectProperty".freeze,
|
1724
1644
|
"vs:term_status": "stable".freeze
|
1725
1645
|
property :hasEnvironmentCharacteristic,
|
1726
|
-
comment: [
|
1646
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/environmentCharacteristic".freeze, "Definition: An assessment of the extent to which the described environment supports its purpose.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: If multiple environments are described, this element can help to distinguish among them.".freeze],
|
1727
1647
|
domain: "premis:Environment".freeze,
|
1728
1648
|
range: term(
|
1729
1649
|
onProperty: "skos:inScheme".freeze,
|
@@ -1733,15 +1653,13 @@ If the application is a Web harvester capturing an object at a point of time, us
|
|
1733
1653
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1734
1654
|
"vs:term_status": "stable".freeze
|
1735
1655
|
property :hasEnvironmentNote,
|
1736
|
-
comment: [
|
1737
|
-
and used with a standalone PDF reader.).freeze, %(Rationale: There may be a need to give a textual description of the environment for additional explanation.).freeze, %(Usage Notes: This note could be used to record the context of the environment information. For example, if a file can be rendered through a PC client application or through a browser with a plug-in, this note could be used to identify which situation applies.
|
1738
|
-
The note should not be used for a textual description of environment information recorded more rigorously elsewhere.).freeze],
|
1656
|
+
comment: ["Definition: Additional information about the environment.".freeze, "Example: This environment assumes that the PDF will be stored locally\nand used with a standalone PDF reader.".freeze, "Rationale: There may be a need to give a textual description of the environment for additional explanation.".freeze, "Usage Notes: This note could be used to record the context of the environment information. For example, if a file can be rendered through a PC client application or through a browser with a plug-in, this note could be used to identify which situation applies.\nThe note should not be used for a textual description of environment information recorded more rigorously elsewhere.".freeze],
|
1739
1657
|
domain: "premis:Environment".freeze,
|
1740
1658
|
range: "xsd:string".freeze,
|
1741
1659
|
type: "owl:DatatypeProperty".freeze,
|
1742
1660
|
"vs:term_status": "stable".freeze
|
1743
1661
|
property :hasEnvironmentPurpose,
|
1744
|
-
comment: [
|
1662
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/environmentPurpose".freeze, "Definition: The use(s) supported by the specified environment.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: Different environments can support different uses of objects. For example, the environment needed to edit and modify a file can be quite different than the environment needed to render it.".freeze],
|
1745
1663
|
domain: "premis:Environment".freeze,
|
1746
1664
|
range: term(
|
1747
1665
|
onProperty: "skos:inScheme".freeze,
|
@@ -1751,7 +1669,7 @@ The note should not be used for a textual description of environment information
|
|
1751
1669
|
type: "owl:ObjectProperty".freeze,
|
1752
1670
|
"vs:term_status": "stable".freeze
|
1753
1671
|
property :hasEvent,
|
1754
|
-
comment: [
|
1672
|
+
comment: ["Definition: The event associated with the object or an agent.".freeze, "Usage Notes: Use to link to events that are not associated with relationships between objects, such as format validation, virus checking, etc.".freeze],
|
1755
1673
|
domain: term(
|
1756
1674
|
type: "owl:Class".freeze,
|
1757
1675
|
unionOf: list("premis:Agent".freeze, "premis:Object".freeze)
|
@@ -1761,21 +1679,19 @@ The note should not be used for a textual description of environment information
|
|
1761
1679
|
type: "owl:ObjectProperty".freeze,
|
1762
1680
|
"vs:term_status": "stable".freeze
|
1763
1681
|
property :hasEventDateTime,
|
1764
|
-
comment: [
|
1682
|
+
comment: ["Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime".freeze, "Definition: The single date and time, or date and time range, at or during which the event occurred.".freeze, "Example: 2001-10-26T19:32:52+00:00".freeze, "Usage Notes: Recommended practice is to record the most specific time possible and to designate the time zone.".freeze],
|
1765
1683
|
domain: "premis:Event".freeze,
|
1766
1684
|
range: "xsd:dateTime".freeze,
|
1767
1685
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1768
1686
|
"vs:term_status": "stable".freeze
|
1769
1687
|
property :hasEventDetail,
|
1770
|
-
comment: [
|
1771
|
-
Program=“MIGJP2JP2K”; version=“2.2”).freeze, %(Usage Notes: eventDetail is not intended to be processed by machine. It may record any information about an event and/or point to information stored elsewhere.).freeze],
|
1688
|
+
comment: ["Definition: Additional information about the event.".freeze, "Examples: Object permanently withdrawn by request of Caroline Hunt, \nProgram=“MIGJP2JP2K”; version=“2.2”".freeze, "Usage Notes: eventDetail is not intended to be processed by machine. It may record any information about an event and/or point to information stored elsewhere.".freeze],
|
1772
1689
|
domain: "premis:Event".freeze,
|
1773
1690
|
range: "xsd:string".freeze,
|
1774
1691
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1775
1692
|
"vs:term_status": "stable".freeze
|
1776
1693
|
property :hasEventOutcome,
|
1777
|
-
comment: [
|
1778
|
-
Recommended practice is to define events with sufficient granularity that each event has a single outcome.).freeze],
|
1694
|
+
comment: ["Data Constraint: Value should be taken from a controlled vocabulary.".freeze, "Definition: A categorization of the overall result of the event in terms of success, partial success, or failure.".freeze, "Examples: 00 [a code meaning “action successfully completed”], CV-01 [a code meaning “checksum validated”]".freeze, "Rationale: A coded way of representing the outcome of an event may be useful for machine processing and reporting. If, for example, a fixity check fails, the event record provides both an actionable and a permanent record.".freeze, "Usage Notes: Recommended practice is to use a controlled vocabulary that a system can act upon automatically. More detail about the outcome may be recorded in eventOutcomeDetail.\nRecommended practice is to define events with sufficient granularity that each event has a single outcome.".freeze],
|
1779
1695
|
domain: "premis:EventOutcomeInformation".freeze,
|
1780
1696
|
range: "xsd:string".freeze,
|
1781
1697
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -1787,7 +1703,7 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1787
1703
|
type: "owl:ObjectProperty".freeze,
|
1788
1704
|
"vs:term_status": "stable".freeze
|
1789
1705
|
property :hasEventOutcomeDetailNote,
|
1790
|
-
comment: [
|
1706
|
+
comment: ["Definition: A detailed description of the result or product of the event in textual form.".freeze, "Examples: LZW compressed file, Non-standard tags found in header".freeze, "Rationale: Additional information in textual form may be needed about the outcome of the event.".freeze],
|
1791
1707
|
domain: "premis:EventOutcomeDetail".freeze,
|
1792
1708
|
range: "xsd:string".freeze,
|
1793
1709
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -1799,7 +1715,7 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1799
1715
|
type: "owl:ObjectProperty".freeze,
|
1800
1716
|
"vs:term_status": "stable".freeze
|
1801
1717
|
property :hasEventRelatedAgent,
|
1802
|
-
comment: [
|
1718
|
+
comment: ["Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.".freeze, "This propety links a Event instance to an Agent instance. Via this property a distinction can be made in the linkingAgent properties based on the domain.".freeze],
|
1803
1719
|
domain: "premis:Event".freeze,
|
1804
1720
|
range: "premis:Agent".freeze,
|
1805
1721
|
"rdfs:seeAlso": "http://id.loc.gov/vocabulary/preservation/eventRelatedAgentRole".freeze,
|
@@ -1807,7 +1723,7 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1807
1723
|
type: "owl:ObjectProperty".freeze,
|
1808
1724
|
"vs:term_status": "unstable".freeze
|
1809
1725
|
property :hasEventRelatedObject,
|
1810
|
-
comment: [
|
1726
|
+
comment: ["Definition: Information about an object associated with an event.".freeze, "Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.".freeze, "Rationale: Digital provenance often requires that relationships between objects and events are documented.".freeze],
|
1811
1727
|
domain: "premis:Event".freeze,
|
1812
1728
|
range: "premis:Object".freeze,
|
1813
1729
|
"rdfs:seeAlso": ["Event class definition and Object class definition".freeze, "http://id.loc.gov/vocabulary/preservation/eventRelatedObjectRole".freeze],
|
@@ -1815,7 +1731,7 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1815
1731
|
type: "owl:ObjectProperty".freeze,
|
1816
1732
|
"vs:term_status": "stable".freeze
|
1817
1733
|
property :hasEventType,
|
1818
|
-
comment: [
|
1734
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/eventType".freeze, "Definition: A categorization of the nature of the event.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: Categorizing events will aid the preservation repository in machine processing of event information, particularly in reporting.".freeze],
|
1819
1735
|
domain: "premis:Event".freeze,
|
1820
1736
|
range: term(
|
1821
1737
|
onProperty: "skos:inScheme".freeze,
|
@@ -1846,13 +1762,13 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1846
1762
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1847
1763
|
"vs:term_status": "stable".freeze
|
1848
1764
|
property :hasFormatName,
|
1849
|
-
comment: [
|
1765
|
+
comment: ["Data Constraint: Value should be taken from a controlled vocabulary.".freeze, "Definition: A designation of the format of the file or bitstream.".freeze, "Examples: Text/sgml, image/tiff/geotiff, Adobe PDF, DES, PGP, base64, unknown, LaTex".freeze, "Usage Notes: For unidentified formats, formatName may be recorded as “unknown”.".freeze],
|
1850
1766
|
domain: "premis:FormatDesignation".freeze,
|
1851
1767
|
range: "xsd:string".freeze,
|
1852
1768
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1853
1769
|
"vs:term_status": "stable".freeze
|
1854
1770
|
property :hasFormatNote,
|
1855
|
-
comment: [
|
1771
|
+
comment: ["Definition: Additional information about format.".freeze, "Examples: tentative identification, disjunction, multiple format identifications found".freeze, "Rationale: Qualifying information may be needed to supplement format designation and registry information or record a status for identification.".freeze, "Usage Notes: The formatNote may contain free text, a reference pointer, or a value from a controlled list.".freeze],
|
1856
1772
|
domain: "premis:Format".freeze,
|
1857
1773
|
range: "xsd:string".freeze,
|
1858
1774
|
type: "owl:DatatypeProperty".freeze,
|
@@ -1864,18 +1780,18 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1864
1780
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1865
1781
|
"vs:term_status": "stable".freeze
|
1866
1782
|
property :hasFormatRegistryKey,
|
1867
|
-
comment: [
|
1783
|
+
comment: ["Definition: The unique key used to reference an entry for this format in a format registry.".freeze, "Examples: info:gdfr/fred/f/tiff, TIFF/6.0".freeze],
|
1868
1784
|
domain: "premis:FormatRegistry".freeze,
|
1869
1785
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1870
1786
|
"vs:term_status": "stable".freeze
|
1871
1787
|
property :hasFormatRegistryName,
|
1872
|
-
comment: [
|
1788
|
+
comment: ["Definition: A designation identifying the referenced format registry.".freeze, "Examples: PRONOM, www.nationalarchives.gov.uk/pronom, Representation Information Registry Repository, FRED: A format registry demonstration, release 0.07".freeze, "Usage Notes: This can be a formal name, internally used name, or URI.".freeze],
|
1873
1789
|
domain: "premis:FormatRegistry".freeze,
|
1874
1790
|
range: "xsd:string".freeze,
|
1875
1791
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1876
1792
|
"vs:term_status": "stable".freeze
|
1877
1793
|
property :hasFormatRegistryRole,
|
1878
|
-
comment: [
|
1794
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/formatRegistryRole".freeze, "Definition: The purpose or expected use of the registry.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: The same format may be defined in different registries for different purposes. For example, one registry may give detailed format specifications while another has profile information. If multiple registries are recorded, this semantic unit can be used to distinguish among them.".freeze],
|
1879
1795
|
domain: "premis:FormatRegistry".freeze,
|
1880
1796
|
range: term(
|
1881
1797
|
onProperty: "skos:inScheme".freeze,
|
@@ -1885,7 +1801,7 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1885
1801
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1886
1802
|
"vs:term_status": "stable".freeze
|
1887
1803
|
property :hasFormatVersion,
|
1888
|
-
comment: [
|
1804
|
+
comment: ["Definition: The version of the format named in formatName.".freeze, "Examples: 6.0, 2003".freeze, "Rationale: Many authority lists of format names are not granular enough to indicate version, for example, MIME Media types.".freeze, "Usage Notes: If the format is versioned, formatVersion should be recorded. It can be either a numeric or chronological designation.".freeze],
|
1889
1805
|
domain: "premis:FormatDesignation".freeze,
|
1890
1806
|
range: "xsd:string".freeze,
|
1891
1807
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -1897,20 +1813,19 @@ Recommended practice is to define events with sufficient granularity that each e
|
|
1897
1813
|
type: "owl:ObjectProperty".freeze,
|
1898
1814
|
"vs:term_status": "stable".freeze
|
1899
1815
|
property :hasHardwareName,
|
1900
|
-
comment: [
|
1901
|
-
Include version for firmware or other components where that information is pertinent.).freeze],
|
1816
|
+
comment: ["Definition: Manufacturer, model, and version (if applicable) of the hardware.".freeze, "Examples: Intel Pentium III, 1 GB DRAM, Windows XPcompatible joystick".freeze, "Usage Notes: Include manufacturer when this helps to identify or disambiguate the product.\nInclude version for firmware or other components where that information is pertinent.".freeze],
|
1902
1817
|
domain: "premis:Hardware".freeze,
|
1903
1818
|
range: "xsd:string".freeze,
|
1904
1819
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1905
1820
|
"vs:term_status": "stable".freeze
|
1906
1821
|
property :hasHardwareOtherInformation,
|
1907
|
-
comment: [
|
1822
|
+
comment: ["Definition: Additional requirements or instructions related to the hardware referenced in hwName.".freeze, "Examples: 32MB minimum, Required RAM for Apache is unknown".freeze, "Rationale: For hardware, the amount of computing resource needed (such as memory, storage, processor speed, etc.) may need to be documented. In addition, more detailed instructions may be needed to install and/or operate the hardware.".freeze, "Usage Notes: This could be an identifier or URI used to point to hardware documentation.".freeze],
|
1908
1823
|
domain: "premis:Hardware".freeze,
|
1909
1824
|
range: "xsd:string".freeze,
|
1910
1825
|
type: "owl:DatatypeProperty".freeze,
|
1911
1826
|
"vs:term_status": "stable".freeze
|
1912
1827
|
property :hasHardwareType,
|
1913
|
-
comment: [
|
1828
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/hardwareType".freeze, "Definition: Class or category of the hardware.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze],
|
1914
1829
|
domain: "premis:Hardware".freeze,
|
1915
1830
|
range: term(
|
1916
1831
|
onProperty: "skos:inScheme".freeze,
|
@@ -1928,25 +1843,25 @@ Include version for firmware or other components where that information is perti
|
|
1928
1843
|
type: ["owl:InverseFunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1929
1844
|
"vs:term_status": "stable".freeze
|
1930
1845
|
property :hasIdentifierType,
|
1931
|
-
comment: [
|
1846
|
+
comment: ["Data Constraint: Value should be taken from controlled vocabulary.".freeze, "Definition: A designation of the domain within which the identifier is unique.".freeze, "Examples: DLC, DRS, hdl:4263537".freeze, "Rationale: Identifier values cannot be assumed to be unique across domains. The combination of identifierType and identifierValue should ensure uniqueness.".freeze, "Usage Notes: The type of the identifier may be implicit within the repository as long it can be explicitly communicated when the item is disseminated outside of it.".freeze],
|
1932
1847
|
domain: "premis:Identifier".freeze,
|
1933
1848
|
range: "xsd:string".freeze,
|
1934
1849
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1935
1850
|
"vs:term_status": "stable".freeze
|
1936
1851
|
property :hasIdentifierValue,
|
1937
|
-
comment: [
|
1852
|
+
comment: ["Defnition: The value of the Identifier.".freeze, "Examples: 0000000312 (Representation), IU2440 (File), WAC1943.56 (File), http://nrs.harvard.edu/urn-3:FHCL.Loeb:sal (File), IU2440-1 (Bitstream)".freeze],
|
1938
1853
|
domain: "premis:Identifier".freeze,
|
1939
1854
|
range: "xsd:string".freeze,
|
1940
1855
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1941
1856
|
"vs:term_status": "stable".freeze
|
1942
1857
|
property :hasInhibitorKey,
|
1943
|
-
comment: [
|
1858
|
+
comment: ["Definition: The decryption key or password.".freeze, "Example: [DES decryption key]".freeze, "Usage Notes: The key should be provided if known. However, it is not advisable to actually store the inhibitorKey in plain text in an unsecure database.".freeze],
|
1944
1859
|
domain: "premis:Inhibitors".freeze,
|
1945
1860
|
range: "xsd:string".freeze,
|
1946
1861
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1947
1862
|
"vs:term_status": "stable".freeze
|
1948
1863
|
property :hasInhibitorTarget,
|
1949
|
-
comment: [
|
1864
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/inhibitorTarget".freeze, "Definition: The content or function protected by the inhibitor.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze],
|
1950
1865
|
domain: "premis:Inhibitors".freeze,
|
1951
1866
|
range: term(
|
1952
1867
|
onProperty: "skos:inScheme".freeze,
|
@@ -1956,7 +1871,7 @@ Include version for firmware or other components where that information is perti
|
|
1956
1871
|
type: "owl:ObjectProperty".freeze,
|
1957
1872
|
"vs:term_status": "stable".freeze
|
1958
1873
|
property :hasInhibitorType,
|
1959
|
-
comment: [
|
1874
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/inhibitorType".freeze, "Definition: The inhibitor method employed.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze],
|
1960
1875
|
domain: "premis:Inhibitors".freeze,
|
1961
1876
|
range: term(
|
1962
1877
|
onProperty: "skos:inScheme".freeze,
|
@@ -1972,7 +1887,7 @@ Include version for firmware or other components where that information is perti
|
|
1972
1887
|
type: "owl:ObjectProperty".freeze,
|
1973
1888
|
"vs:term_status": "stable".freeze
|
1974
1889
|
property :hasIntellectualEntity,
|
1975
|
-
comment: [
|
1890
|
+
comment: ["Definition: An intellectual entity associated with the object.".freeze, "Usage Notes: Use to link to an intellectual entity that is related to the object. This may be a link to descriptive metadata that describes the intellectual entity or some other surrogate for it that can be referenced. This link will likely be to an identifier of an object that is at a higher conceptual level than the object for which the metadata is provided, for example, to a collection or parent object.".freeze],
|
1976
1891
|
domain: "premis:Object".freeze,
|
1977
1892
|
range: "premis:IntellectualEntity".freeze,
|
1978
1893
|
type: "owl:ObjectProperty".freeze,
|
@@ -1983,19 +1898,19 @@ Include version for firmware or other components where that information is perti
|
|
1983
1898
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
1984
1899
|
"vs:term_status": "unstable".freeze
|
1985
1900
|
property :hasLicenseTerms,
|
1986
|
-
comment: [
|
1901
|
+
comment: ["Definition: Text describing the license or agreement by which permission was granted.".freeze, "Usage Notes: This could contain the actual text of the license or agreement or a paraphrase or summary.".freeze],
|
1987
1902
|
domain: "premis:LicenseInformation".freeze,
|
1988
1903
|
range: "xsd:string".freeze,
|
1989
1904
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1990
1905
|
"vs:term_status": "stable".freeze
|
1991
1906
|
property :hasMessageDigest,
|
1992
|
-
comment: [
|
1907
|
+
comment: ["Definition: The output of the message digest algorithm.".freeze, "Example: 7c9b35da4f2ebd436f1cf88e5a39b3a257edf4a22be3c955ac49da2e2107b67a1924419563".freeze, "Rationale: This must be stored so that it can be compared in future fixity checks.".freeze],
|
1993
1908
|
domain: "premis:Fixity".freeze,
|
1994
1909
|
range: "xsd:string".freeze,
|
1995
1910
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
1996
1911
|
"vs:term_status": "stable".freeze
|
1997
1912
|
property :hasMessageDigestAlgorithm,
|
1998
|
-
comment: [
|
1913
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/cryptographicHashFunctions".freeze, "Definition: The specific algorithm used to construct the message digest for the digital object.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze],
|
1999
1914
|
domain: "premis:Fixity".freeze,
|
2000
1915
|
range: term(
|
2001
1916
|
onProperty: "skos:inScheme".freeze,
|
@@ -2005,13 +1920,13 @@ Include version for firmware or other components where that information is perti
|
|
2005
1920
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
2006
1921
|
"vs:term_status": "stable".freeze
|
2007
1922
|
property :hasMessageDigestOriginator,
|
2008
|
-
comment: [
|
1923
|
+
comment: ["Creation / Maintenance Notes: If the calculation of the initial message digest is treated by the repository as an Event, this information could be obtained from an Event record.".freeze, "Definition: The agent that created the original message digest that is compared in a fixity check.".freeze, "Examples: DRS, A0000978".freeze, "Rationale: A preservation repository may ingest files that have had message digests calculated by the submitter; checking these ensures that the file as received is the same as the file as sent. The repository may also ingest files that do not have message digests, and so must calculate the initial value upon ingest. It can be useful to know who calculated the initial value of the message digest.".freeze, "Usage Notes: The originator of the message digest could be represented by a string representing the agent (e.g., “NRS” referring to the archive itself) or a pointer to an agent description (e.g., “A0000987” taken here to be an agentIdentifierValue).".freeze],
|
2009
1924
|
domain: "premis:Fixity".freeze,
|
2010
1925
|
range: "xsd:string".freeze,
|
2011
1926
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2012
1927
|
"vs:term_status": "stable".freeze
|
2013
1928
|
property :hasObject,
|
2014
|
-
comment: [
|
1929
|
+
comment: ["Definition: Information about an object associated with an event or rightsstatement.".freeze, "Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.".freeze, "Rationale: Digital provenance often requires that relationships between objects and events are documented. / Rights statements must be associated with the objects to which they pertain, either by linking from the rights statement to the object(s) or by linking from the object(s) to the rights statement. This provides the mechanism for the link from the rights statement to an object. For denoting the role of the object, when related to an event,one can extend this ontology be defining your own subproperties, such as those given by http://id.loc.gov/vocabulary/preservation/eventRelatedObjectRole.".freeze],
|
2015
1930
|
domain: term(
|
2016
1931
|
type: "owl:Class".freeze,
|
2017
1932
|
unionOf: list("premis:Event".freeze, "premis:RightsStatement".freeze)
|
@@ -2030,7 +1945,7 @@ Include version for firmware or other components where that information is perti
|
|
2030
1945
|
type: ["owl:InverseFunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
2031
1946
|
"vs:term_status": "stable".freeze
|
2032
1947
|
property :hasOriginalName,
|
2033
|
-
comment: [
|
1948
|
+
comment: ["Creation / Maintenance Notes: This value would always be supplied to the repository by the submitter or harvesting application. How much of the file path to preserve would be up to the repository.".freeze, "Definition: The name of the object as submitted to or harvested by the repository, before any renaming by the repository.".freeze, "Example: N419.pdf".freeze, "Rationale: The name used within the preservation repository may not be known outside of the repository. A depositor might need to request a file by its original name. Also, the repository may need to reconstruct internal links for dissemination.".freeze, "Usage Notes: This is the name of the object as designated in the Submission Information Package (SIP). The object may have other names in different contexts. When two repositories are exchanging content, it would be important for the receiving repository to know and record the name of the representation at the originating repository. In the case of representations, this may be a directory name.".freeze],
|
2034
1949
|
domain: term(
|
2035
1950
|
type: "owl:Class".freeze,
|
2036
1951
|
unionOf: list("premis:File".freeze, "premis:Representation".freeze)
|
@@ -2048,24 +1963,19 @@ Include version for firmware or other components where that information is perti
|
|
2048
1963
|
type: "owl:ObjectProperty".freeze,
|
2049
1964
|
"vs:term_status": "stable".freeze
|
2050
1965
|
property :hasPreservationLevelDateAssigned,
|
2051
|
-
comment: [
|
1966
|
+
comment: ["Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime".freeze, "Definition: The date, or date and time, when a particular preservationLevelValue was assigned to the object.".freeze, "Examples: 2001-10-26T19:32:52+00:00".freeze, "Rationale: The preservationLevel applicable to an object is expected to be reviewed and changed over time, in response to changes in repository preservation requirements, policies, or capabilities relevant to the object. The date that the current preservationLevelValue was assigned aids review of decisions.".freeze],
|
2052
1967
|
domain: "premis:PreservationLevel".freeze,
|
2053
1968
|
range: "xsd:dateTime".freeze,
|
2054
1969
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2055
1970
|
"vs:term_status": "stable".freeze
|
2056
1971
|
property :hasPreservationLevelRationale,
|
2057
|
-
comment: [
|
2058
|
-
the object.).freeze, %(Examples: user pays, legislation, defective file, bit-level preservation only available for this format).freeze, %(Rationale: Application of a particular preservationLevelValue may require justification, especially if it differs from that usually applied according to repository policy.).freeze, %(Usage Notes: This optional semantic unit records the reason for applying the preservationLevelValue.
|
2059
|
-
This information can be particularly important when the assigned preservationLevelValue differs from usual repository policy.
|
2060
|
-
For example, a repository may normally assign a preservationLevelValue of “full preservation” for JPEG2000 files, but detects that a particular file is defective. This may mean that the repository’s preservation strategy for JPEG2000 may not be effective for this particular file, so the repository may assign a preservationLevelValue of “bit-level preservation” to this file, recording “defective file” as the rationale.
|
2061
|
-
Similarly, legislative requirements or contractual agreements may require a higher level of preservation to be assigned to a particular object than would be assigned to that class of object according to usual policy. In this case, the rationale for the assignment may be recorded as “legislation” or “user pays”, for example.
|
2062
|
-
preservationLevelRationale may be repeated if more than one reason needs to be recorded.).freeze],
|
1972
|
+
comment: ["Definition: The reason a particular preservationLevelValue was applied to \n the object.".freeze, "Examples: user pays, legislation, defective file, bit-level preservation only available for this format".freeze, "Rationale: Application of a particular preservationLevelValue may require justification, especially if it differs from that usually applied according to repository policy.".freeze, "Usage Notes: This optional semantic unit records the reason for applying the preservationLevelValue.\nThis information can be particularly important when the assigned preservationLevelValue differs from usual repository policy.\nFor example, a repository may normally assign a preservationLevelValue of “full preservation” for JPEG2000 files, but detects that a particular file is defective. This may mean that the repository’s preservation strategy for JPEG2000 may not be effective for this particular file, so the repository may assign a preservationLevelValue of “bit-level preservation” to this file, recording “defective file” as the rationale.\nSimilarly, legislative requirements or contractual agreements may require a higher level of preservation to be assigned to a particular object than would be assigned to that class of object according to usual policy. In this case, the rationale for the assignment may be recorded as “legislation” or “user pays”, for example.\npreservationLevelRationale may be repeated if more than one reason needs to be recorded.".freeze],
|
2063
1973
|
domain: "premis:PreservationLevel".freeze,
|
2064
1974
|
range: "xsd:string".freeze,
|
2065
1975
|
type: "owl:DatatypeProperty".freeze,
|
2066
1976
|
"vs:term_status": "stable".freeze
|
2067
1977
|
property :hasPreservationLevelRole,
|
2068
|
-
comment: [
|
1978
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/preservationLevelRole".freeze, "Definition: A value indicating the context in which a set of preservation options is applicable.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: Repositories may assign preservationLevelValues in different contexts which must be differentiated, and may need to record more than one context.".freeze],
|
2069
1979
|
domain: "premis:PreservationLevel".freeze,
|
2070
1980
|
range: term(
|
2071
1981
|
onProperty: "skos:inScheme".freeze,
|
@@ -2075,32 +1985,31 @@ preservationLevelRationale may be repeated if more than one reason needs to be r
|
|
2075
1985
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
2076
1986
|
"vs:term_status": "stable".freeze
|
2077
1987
|
property :hasPreservationLevelValue,
|
2078
|
-
comment: [
|
1988
|
+
comment: ["Creation / Maintenance Notes: The preservation level may be assigned by the repository or requested by the depositor and submitted as metadata.".freeze, "Data Constraint: Value should be taken from a controlled vocabulary.".freeze, "Definition: A value indicating the set of preservation functions expected to be applied to the object.".freeze, "Examples: bit-level, full, fully supported with future migrations (File), 0".freeze, "Rationale: Some preservation repositories will offer multiple preservation options depending on factors such as the value or uniqueness of the material, the “preservability” of the format, the amount the customer is willing to pay, etc.".freeze, "Usage Notes: Only one preservationLevelValue may be recorded per preservationLevel container. If a further preservationLevelValue applies to the object in a different context, a separate preservationLevel container should be repeated.".freeze],
|
2079
1989
|
domain: "premis:PreservationLevel".freeze,
|
2080
1990
|
range: "xsd:string".freeze,
|
2081
1991
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2082
1992
|
"vs:term_status": "stable".freeze
|
2083
1993
|
property :hasRelatedObject,
|
2084
|
-
comment:
|
1994
|
+
comment: "Definition: This property related to all object belonging to a RelatedObjectIdentification to describe the related objects as an aggregation.".freeze,
|
2085
1995
|
domain: "premis:RelatedObjectIdentification".freeze,
|
2086
1996
|
range: "premis:Object".freeze,
|
2087
1997
|
type: "owl:ObjectProperty".freeze,
|
2088
1998
|
"vs:term_status": "stable".freeze
|
2089
1999
|
property :hasRelatedObjectSequence,
|
2090
|
-
comment: [
|
2091
|
-
type of relationship.).freeze, %(Rationale: This semantic unit is particularly useful for structural relationships. In order to reconstruct a representation, it may be necessary to know the order of components with sibling or part-whole relationships. For example, to render a page-image book, it is necessary to know the order of files representing pages.).freeze],
|
2000
|
+
comment: ["Definition: The order of the related object relative to other objects with the same\ntype of relationship.".freeze, "Rationale: This semantic unit is particularly useful for structural relationships. In order to reconstruct a representation, it may be necessary to know the order of components with sibling or part-whole relationships. For example, to render a page-image book, it is necessary to know the order of files representing pages.".freeze],
|
2092
2001
|
domain: "premis:RelatedObjectIdentification".freeze,
|
2093
2002
|
range: "xsd:string".freeze,
|
2094
2003
|
type: "owl:DatatypeProperty".freeze,
|
2095
2004
|
"vs:term_status": "stable".freeze
|
2096
2005
|
property :hasRelatedStatuteInformation,
|
2097
|
-
comment:
|
2006
|
+
comment: "Definition: This property is used to relate certain StatuteInformation instances. The rationale for this is that in the PREMIS data dictionary, a RightsStatement instance can consist of several StatuteInformation instances. In the PREMIS OWL ontology, the StatuteInformation class is subclassed to RightsStatement. The restore the relation between the grouped StatuteInformation instances of a RightsStatement of the PREMIS data dictionary, this property is used is PREMIS OWL.".freeze,
|
2098
2007
|
domain: "premis:StatuteInformation".freeze,
|
2099
2008
|
range: "premis:StatuteInformation".freeze,
|
2100
2009
|
type: "owl:ObjectProperty".freeze,
|
2101
2010
|
"vs:term_status": "stable".freeze
|
2102
2011
|
property :hasRelationship,
|
2103
|
-
comment: [
|
2012
|
+
comment: ["Definition: This property links one object to one or more other objects.".freeze, "Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.".freeze, "The LOC will provide a SKOS vocabulary, where the concepts can also be used as object properties at http://id.loc.gov/. These relationships will capture the relationship type and subtype. One can define its own relationships, but for interoperability reasons, these should be linked to or made a subproperty of the properties of the LOC vocabulary.".freeze],
|
2104
2013
|
domain: "premis:Object".freeze,
|
2105
2014
|
range: term(
|
2106
2015
|
type: "owl:Class".freeze,
|
@@ -2110,7 +2019,7 @@ type of relationship.).freeze, %(Rationale: This semantic unit is particularly u
|
|
2110
2019
|
type: "owl:ObjectProperty".freeze,
|
2111
2020
|
"vs:term_status": "testing".freeze
|
2112
2021
|
property :hasRestriction,
|
2113
|
-
comment: [
|
2022
|
+
comment: ["Definition: A condition or limitation on the act.".freeze, "Examples: No more than three, Allowed only after one year of archival retention has elapsed, Rightsholder must be notified after completion of act".freeze],
|
2114
2023
|
domain: "premis:RightsGranted".freeze,
|
2115
2024
|
range: "xsd:string".freeze,
|
2116
2025
|
type: "owl:DatatypeProperty".freeze,
|
@@ -2122,7 +2031,7 @@ type of relationship.).freeze, %(Rationale: This semantic unit is particularly u
|
|
2122
2031
|
type: "owl:ObjectProperty".freeze,
|
2123
2032
|
"vs:term_status": "stable".freeze
|
2124
2033
|
property :hasRightsDocumentationRole,
|
2125
|
-
comment: [
|
2034
|
+
comment: ["Definition: This property denotes the role of the related documentation. The value must be taken from a skos vocabulary. A value indicating the purpose or expected use of the documentation being identified.".freeze, "Rationale: This information distinguishes the purpose of the supporting documentation especially when there are multiple documentation identifiers.".freeze],
|
2126
2035
|
domain: "premis:RightsDocumentation".freeze,
|
2127
2036
|
range: "skos:Concept".freeze,
|
2128
2037
|
type: "owl:ObjectProperty".freeze,
|
@@ -2134,13 +2043,13 @@ type of relationship.).freeze, %(Rationale: This semantic unit is particularly u
|
|
2134
2043
|
type: "owl:ObjectProperty".freeze,
|
2135
2044
|
"vs:term_status": "stable".freeze
|
2136
2045
|
property :hasRightsGrantedNote,
|
2137
|
-
comment: [
|
2046
|
+
comment: ["Definition: Additional information about the rights granted.".freeze, "Rationale: A textual description of the rights granted may be needed for additional explanation.".freeze, "Usage Notes: This semantic unit may include a statement about risk assessment, for example, when a repository is not certain about what permissions have been granted.".freeze],
|
2138
2047
|
domain: "premis:RightsGranted".freeze,
|
2139
2048
|
range: "xsd:string".freeze,
|
2140
2049
|
type: "owl:DatatypeProperty".freeze,
|
2141
2050
|
"vs:term_status": "stable".freeze
|
2142
2051
|
property :hasRightsRelatedAgent,
|
2143
|
-
comment: [
|
2052
|
+
comment: ["Extensions: One can extend this property to use more fine grained properties by defining the fine grained properties as subproperties of this property.".freeze, "This propety links a RightsStatement instance to an Agent instance. Via this property a distinction can be made in the linkingAgent properties based on the domain.".freeze],
|
2144
2053
|
domain: "premis:RightsStatement".freeze,
|
2145
2054
|
range: "premis:Agent".freeze,
|
2146
2055
|
"rdfs:seeAlso": "http://id.loc.gov/vocabulary/preservation/rightsRelatedAgentRole".freeze,
|
@@ -2148,7 +2057,7 @@ type of relationship.).freeze, %(Rationale: This semantic unit is particularly u
|
|
2148
2057
|
type: "owl:ObjectProperty".freeze,
|
2149
2058
|
"vs:term_status": "unstable".freeze
|
2150
2059
|
property :hasRightsStatement,
|
2151
|
-
comment: [
|
2060
|
+
comment: ["Definition: A rights statement associated with the object.".freeze, "Rationale: A repository may choose to link from a rights statement to an object or from an object to a rights statement or both.".freeze],
|
2152
2061
|
domain: term(
|
2153
2062
|
type: "owl:Class".freeze,
|
2154
2063
|
unionOf: list("premis:Agent".freeze, "premis:Object".freeze)
|
@@ -2158,8 +2067,7 @@ type of relationship.).freeze, %(Rationale: This semantic unit is particularly u
|
|
2158
2067
|
type: "owl:ObjectProperty".freeze,
|
2159
2068
|
"vs:term_status": "stable".freeze
|
2160
2069
|
property :hasRightsStatementNote,
|
2161
|
-
comment: [
|
2162
|
-
License is embedded in XMP block in file header.).freeze],
|
2070
|
+
comment: ["Definition: Additional information about the RightsStatement of an object.".freeze, "Examples: Copyright expiration expected in 2010 unless renewed.\nLicense is embedded in XMP block in file header.".freeze],
|
2163
2071
|
domain: "premis:RightsStatement".freeze,
|
2164
2072
|
range: "xsd:string".freeze,
|
2165
2073
|
type: "owl:DatatypeProperty".freeze,
|
@@ -2174,7 +2082,7 @@ License is embedded in XMP block in file header.).freeze],
|
|
2174
2082
|
type: "owl:ObjectProperty".freeze,
|
2175
2083
|
"vs:term_status": "stable".freeze
|
2176
2084
|
property :hasSignatureEncoding,
|
2177
|
-
comment: [
|
2085
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/signatureEncoding".freeze, "Definition: The encoding used for the values of signatureValue, keyInformation.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: These values cannot be interpreted correctly if the encoding is unknown.".freeze],
|
2178
2086
|
domain: "premis:Signature".freeze,
|
2179
2087
|
range: term(
|
2180
2088
|
onProperty: "skos:inScheme".freeze,
|
@@ -2184,32 +2092,31 @@ License is embedded in XMP block in file header.).freeze],
|
|
2184
2092
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
2185
2093
|
"vs:term_status": "stable".freeze
|
2186
2094
|
property :hasSignatureMethod,
|
2187
|
-
comment: [
|
2095
|
+
comment: ["Data Constraint: Values are taken from a SKOS vocabulary".freeze, "Definition: A designation for the encryption and hash algorithms used for signature generation.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: The same algorithms must be used for signature validation.".freeze],
|
2188
2096
|
domain: "premis:Signature".freeze,
|
2189
2097
|
range: "skos:Concept".freeze,
|
2190
2098
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
2191
2099
|
"vs:term_status": "stable".freeze
|
2192
2100
|
property :hasSignatureProperties,
|
2193
|
-
comment: [
|
2101
|
+
comment: ["Definition: Additional information about the generation of the signature.".freeze, "Usage Notes: This may include the date/time of signature generation, the serial number of the cryptographic hardware used, or other information related to the generation of the signature. Repositories will likely want to define a suitably granular structure to signatureProperties.".freeze],
|
2194
2102
|
domain: "premis:Signature".freeze,
|
2195
2103
|
range: "xsd:string".freeze,
|
2196
2104
|
type: "owl:DatatypeProperty".freeze,
|
2197
2105
|
"vs:term_status": "stable".freeze
|
2198
2106
|
property :hasSignatureValidationRules,
|
2199
|
-
comment: [
|
2200
|
-
This value could also be a pointer to archive documentation.).freeze],
|
2107
|
+
comment: ["Definition: The operations to be performed in order to validate the digital signature.".freeze, "Rationale: The repository should not assume that the procedure for validating any particular signature will be known many years in the future without documentation.".freeze, "Usage Notes: This may include the canonicalization method used before calculating the message digest, if the object was normalized before signing.\nThis value could also be a pointer to archive documentation.".freeze],
|
2201
2108
|
domain: "premis:Signature".freeze,
|
2202
2109
|
range: "xsd:string".freeze,
|
2203
2110
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2204
2111
|
"vs:term_status": "stable".freeze
|
2205
2112
|
property :hasSignatureValue,
|
2206
|
-
comment: [
|
2113
|
+
comment: ["Definition: The digital signature; a value generated from the application of a private key to a message digest.".freeze, "Example: juS5RhJ884qoFR8flVXd/rbrSDVGn40CapgB7qeQiT+rr0NekEQ6BHhUA8dT3+BCTBUQI0dBjlml9lwzENXvS83zRECjzXbMRTUtVZiPZG2pqKPnL2YU3A9645UCjTXU+jgFumv7k78hieAGDzNci+PQ9KRmm//icT7JaYztgt4=".freeze],
|
2207
2114
|
domain: "premis:Signature".freeze,
|
2208
2115
|
range: "xsd:string".freeze,
|
2209
2116
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2210
2117
|
"vs:term_status": "stable".freeze
|
2211
2118
|
property :hasSigner,
|
2212
|
-
comment: [
|
2119
|
+
comment: ["Definition: The individual, institution, or authority responsible for generating the signature.".freeze, "Rationale: The signer might also be carried in the keyInformation, but it can be accessed more conveniently if recorded here.".freeze, "Usage Notes: If the signer is an Agent known to the repository, this property can directly link to this agent. The consequence is punning: a datatype property and object property with the same name, i.e., :signer".freeze],
|
2213
2120
|
domain: "premis:Signature".freeze,
|
2214
2121
|
range: ["premis:Agent".freeze, "xsd:string".freeze],
|
2215
2122
|
type: "owl:AnnotationProperty".freeze,
|
@@ -2221,21 +2128,19 @@ This value could also be a pointer to archive documentation.).freeze],
|
|
2221
2128
|
type: "owl:ObjectProperty".freeze,
|
2222
2129
|
"vs:term_status": "stable".freeze
|
2223
2130
|
property :hasSignificantPropertiesType,
|
2224
|
-
comment: [
|
2131
|
+
comment: ["Definition: The aspect, facet, or attribute of an object about which significant properties are being described.".freeze, "Examples: content, structure, behavior, page count, page width, typeface, hyperlinks (representation), image count (representation), color space [for an embedded image] (bitstream)".freeze, "Rationale: Repositories may choose to describe significant properties based on a particular aspect or attribute of an object.".freeze, "Usage Notes: This semantic unit is optional and may be used as part of a facet:detail pair with significantPropertiesValue.".freeze],
|
2225
2132
|
domain: "premis:SignificantProperties".freeze,
|
2226
2133
|
range: "xsd:string".freeze,
|
2227
2134
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2228
2135
|
"vs:term_status": "stable".freeze
|
2229
2136
|
property :hasSignificantPropertiesValue,
|
2230
|
-
comment: [
|
2231
|
-
If facet:detail pairs are not used, significantPropertiesValue may be used to freely describe any characteristic of an object.
|
2232
|
-
significantPropertiesValue is not repeatable. Multiple significant properties should be described in separate, repeated significantProperties container units.).freeze],
|
2137
|
+
comment: ["Definition: Description of the characteristics of a particular object subjectively determined to be important to maintain through preservation actions.".freeze, "Examples: [For a Web page containing animation that is not considered essential] Content only, [For detail associated with a significantPropertiesType of \"behavior\"] Hyperlinks traversable, [For a Word document with embedded links that are not considered essential] Content only, [For detail associated with significantPropertiesType of \"behavior\"] Editable, [For detail associated with a significantPropertiesType of \"page width\"] 210 mm, [For a PDF with an embedded graph, where the lines' color determines the lines' meaning] Color, [For detail associated with a significantPropertiesType of \"appearance\"] Color".freeze, "Rationale: Repositories may choose to describe significant properties based on a particular aspect or attribute of an object.".freeze, "Usage Notes: If facet:detail pairs are used, the content of significantPropertiesValue should describe the significant properties of object relevant to the aspect, facet, or attribute declared in the significantPropertiesType with which it is paired.\nIf facet:detail pairs are not used, significantPropertiesValue may be used to freely describe any characteristic of an object.\nsignificantPropertiesValue is not repeatable. Multiple significant properties should be described in separate, repeated significantProperties container units.".freeze],
|
2233
2138
|
domain: "premis:SignificantProperties".freeze,
|
2234
2139
|
range: "xsd:string".freeze,
|
2235
2140
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2236
2141
|
"vs:term_status": "stable".freeze
|
2237
2142
|
property :hasSize,
|
2238
|
-
comment: [
|
2143
|
+
comment: ["Creation / Maintenance Notes: Automatically obtained by the repository.".freeze, "Definition: The size in bytes of the file or bitstream stored in the repository.".freeze, "Example: 2038937".freeze, "Rationale: Size is useful for ensuring the correct number of bytes from storage have been retrieved and that an application has enough room to move or process files. It might also be used when billing for storage.".freeze, "Usage Notes: Defining this semantic unit as size in bytes makes it unnecessary to record a unit of measurement. However, for the purpose of data exchange the unit of measurement should be stated or understood by both partners.".freeze],
|
2239
2144
|
domain: "premis:ObjectCharacteristics".freeze,
|
2240
2145
|
range: "xsd:long".freeze,
|
2241
2146
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -2247,25 +2152,25 @@ significantPropertiesValue is not repeatable. Multiple significant properties sh
|
|
2247
2152
|
type: "owl:ObjectProperty".freeze,
|
2248
2153
|
"vs:term_status": "stable".freeze
|
2249
2154
|
property :hasSoftwareDependency,
|
2250
|
-
comment: [
|
2155
|
+
comment: ["Definition: The name and, if applicable, version of any software component needed by the software referenced in swName in the context of using this object.".freeze, "Example: GNU gcc >=2.7.2".freeze, "Usage Notes: The value should be constructed in a way that is consistent with the construction of swName and swVersion. This semantic unit identifies the software that is needed by what is recorded in swName, for example, a Perl script that depends on a Perl module. In this case the Perl script is listed in swName, with the module in swDependency within a software container.".freeze],
|
2251
2156
|
domain: "premis:Software".freeze,
|
2252
2157
|
range: "xsd:string".freeze,
|
2253
2158
|
type: "owl:DatatypeProperty".freeze,
|
2254
2159
|
"vs:term_status": "stable".freeze
|
2255
2160
|
property :hasSoftwareName,
|
2256
|
-
comment: [
|
2161
|
+
comment: ["Definition: Manufacturer and title of the software application.".freeze, "Examples: Adobe Photoshop, Adobe Acrobat Reader".freeze, "Usage Notes: Include manufacturer when this helps to identify or disambiguate the product, for example, use “Adobe Photoshop” rather than “Photoshop.”".freeze],
|
2257
2162
|
domain: "premis:Software".freeze,
|
2258
2163
|
range: "xsd:string".freeze,
|
2259
2164
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2260
2165
|
"vs:term_status": "stable".freeze
|
2261
2166
|
property :hasSoftwareOtherInformation,
|
2262
|
-
comment: [
|
2167
|
+
comment: ["Definition: Additional requirements or instructions related to the software referenced in swName.".freeze, "Example: Install Acroread (Adobe Acrobat) first; copy nppdf.so (the plug-in) to your Mozilla plug-ins directory, and make sure a copy of (or symlink to) Acroread is in your PATH.".freeze, "Usage Notes: This could be a reliable persistent identifier or URI pointing to software documentation within or outside the repository.".freeze],
|
2263
2168
|
domain: "premis:Software".freeze,
|
2264
2169
|
range: "xsd:string".freeze,
|
2265
2170
|
type: "owl:DatatypeProperty".freeze,
|
2266
2171
|
"vs:term_status": "stable".freeze
|
2267
2172
|
property :hasSoftwareType,
|
2268
|
-
comment: [
|
2173
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/softwareType".freeze, "Definition: Class or category of software.".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: Several different layers of software can be required to support an object.".freeze],
|
2269
2174
|
domain: "premis:Software".freeze,
|
2270
2175
|
range: term(
|
2271
2176
|
onProperty: "skos:inScheme".freeze,
|
@@ -2275,31 +2180,31 @@ significantPropertiesValue is not repeatable. Multiple significant properties sh
|
|
2275
2180
|
type: ["owl:FunctionalProperty".freeze, "owl:ObjectProperty".freeze],
|
2276
2181
|
"vs:term_status": "stable".freeze
|
2277
2182
|
property :hasSoftwareVersion,
|
2278
|
-
comment: [
|
2183
|
+
comment: ["Definition: The version or versions of the software referenced in swName.".freeze, "Examples: >=2.2.0, 6.0, 2003".freeze, "Usage Notes: If there is no formal version, the date of issuance can be used.".freeze],
|
2279
2184
|
domain: "premis:Software".freeze,
|
2280
2185
|
range: "xsd:string".freeze,
|
2281
2186
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2282
2187
|
"vs:term_status": "stable".freeze
|
2283
2188
|
property :hasStartDate,
|
2284
|
-
comment: [
|
2189
|
+
comment: ["Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime".freeze, "Definition: The beginning date of the permission granted.".freeze],
|
2285
2190
|
domain: "premis:ApplicableDates".freeze,
|
2286
2191
|
range: "xsd:dateTime".freeze,
|
2287
2192
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2288
2193
|
"vs:term_status": "stable".freeze
|
2289
2194
|
property :hasStatuteCitation,
|
2290
|
-
comment: [
|
2195
|
+
comment: ["Definition: An identifying designation for the statute.".freeze, "Examples: Legal Deposit (Jersey) Law 200, National Library of New Zealand (Te Puna Mātauranga o Aotearoa) Act 2003 no 19 part 4 s 34".freeze, "Usage Notes: Use standard citation form when applicable.".freeze],
|
2291
2196
|
domain: "premis:StatuteInformation".freeze,
|
2292
2197
|
range: "xsd:string".freeze,
|
2293
2198
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2294
2199
|
"vs:term_status": "stable".freeze
|
2295
2200
|
property :hasStatuteInformationDeterminationDate,
|
2296
|
-
comment: [
|
2201
|
+
comment: ["Data Constraint: To aid machine processing, value should use a structured form: xsd:dateTime".freeze, "Definition: The date that the determination was made that the statute authorized the permission(s) noted.".freeze, "Example: 2001-10-26T19:32:52+00:00".freeze, "Rationale: The permission in question may be the subject of some interpretation. These assessments are made within a specific context and at a specific time. At another time the context, and therefore the assessment, could change. For this reason it can be important to record the date of the decision.".freeze],
|
2297
2202
|
domain: "premis:StatuteInformation".freeze,
|
2298
2203
|
range: "xsd:dateTime".freeze,
|
2299
2204
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
2300
2205
|
"vs:term_status": "stable".freeze
|
2301
2206
|
property :hasStatuteJurisdiction,
|
2302
|
-
comment: [
|
2207
|
+
comment: ["Data Constraint: Values should be taken from a controlled vocabulary.".freeze, "Definition: The country or other political body enacting the statute.".freeze, "Examples: us, de, be".freeze, "Rationale: The connection between the object and the rights granted is based on jurisdiction.".freeze],
|
2303
2208
|
domain: "premis:StatuteInformation".freeze,
|
2304
2209
|
range: "xsd:string".freeze,
|
2305
2210
|
type: ["owl:DatatypeProperty".freeze, "owl:FunctionalProperty".freeze],
|
@@ -2314,7 +2219,7 @@ significantPropertiesValue is not repeatable. Multiple significant properties sh
|
|
2314
2219
|
type: "owl:ObjectProperty".freeze,
|
2315
2220
|
"vs:term_status": "stable".freeze
|
2316
2221
|
property :hasStorageMedium,
|
2317
|
-
comment: [
|
2222
|
+
comment: ["Data Constraint: Values are taken from the SKOS vocabulary: http://id.loc.gov/vocabulary/preservation/storageMedium".freeze, "Definition: The physical medium on which the object is stored (e.g., magnetic tape, hard disk, CD-ROM, DVD).".freeze, "Extensions: One can use its own SKOS vocabulary to use for this property. The precondition to do this, is to link your SKOS concepts to the SKOS concepts of the id.loc.gov vocabulary.".freeze, "Rationale: The repository needs to know the medium on which an object is stored in order to know how and when to do media refreshment and media migration.".freeze],
|
2318
2223
|
domain: "premis:Storage".freeze,
|
2319
2224
|
range: term(
|
2320
2225
|
onProperty: "skos:inScheme".freeze,
|