ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Requirement in required by 5.37?
2
profiles list valid vocabulary terms for a metadata usage environment (5.37)yes, but it's not very explicit. Actually it sounds a bit more like a definition of profiles, in which 5.37 naturally fits
3
4
profile vocabulary lists may be defined as closed (no other terms are allowed) or open (other terms are allowed) (5.37)I think we can say we support this requirment. In practice some of the profiles are currently closed (because they're based on XML Schema, but as most of our models are in fact RDF-based, if they were implemented in a 'real RDF way' then there could be other elements used and we would just ignore them. This is in 'Europeana needs to be able to accept the data described using EDM extensions that are compatible with its EDM-external profile whether it doesn't ingest this data entirely (i.e. some elements will be left out are they are useless for the main Europeana Collections portal) or it does ingest it '
5
6
conceptually, profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles (5.37)yes
7
8
profiles can be "cascading", inheriting from other profiles or profile fragments (discussion at first f2f)yes
9
10
profiles reuse vocabulary terms defined elsewhere (Dublin Core profiles; no use case)yes, but it's not very explicit. Actually it sounds a bit more like a definition of profiles, in which 5.37 naturally fits
11
12
profiles must be able to define finer-grained semantics for vocabulary terms that are used (visible in DCAT APs)yes, this is probably again something that we'd like to have straight in the definition of what a profile is.
13
14
profiles must be able to express rules that support data validation (cardinality, valid values) (5.41)yes
15
16
profiles must be able to express cardinality rules of vocabulary terms (5.41)yes but this is already in the requirement above, I'd say
17
18
profiles can contain links to detailed validation rules or to validation applications that can process the profile (5.48)we don't have it but it seems useful. Or maybe one can say that we have it when we mention re-use of existing machine-specs: "Machine-readable specifications of application profiles need to be easily publishable, and optimize re-use of existing specification."
19
20
profiles must be able to support information that can drive data creation functions, including brief and detailed documentation (5.46)This sounds good but I'm wondering about the focus on data creation. Couldn't any good documentation of a profile be said to facilitate data creation?
21
22
profiles must be able to express what standards (including creation rules) the data conforms to (5.43) (5.42)we don't have it but it sounds good. something like using dcterms:conformsTo?
23
24
profiles must support discoverability via search engines (5.40)To me the case in 5.40 is more specific: it is about mapping profiles to Schema.org - even though the expected end result is indeed that this mapping supports discoverability via search engines
25
26
profiles must have identifiers that can be used to link the DCAT description to the relevant profile (seems obvious; no use case)yes
27
28
*Not covered* (because I didn't know what the requirement would be): 5.3 Responses can conform to multiple, modular profiles (by Ruben)this is in, considering that the following requirements in our list apply to situation where data can comply with several profiles: - Data publishers (data providers, intermediary aggregators, Europeana and DPLA) need to be able to indicate the profile to which a certain piece of data (record describing an individual cultural object, or a whole dataset) belong.
- Data consumers (intermediary aggregators, Europeana and DPLA, data consumers) need to be able to specify the profile they are interested in
29
30
31
Other requirements not in the list above, maybe because they're rather about profile negotiation then profile definition
32
Data publishers (data providers, intermediary aggregators, Europeana and DPLA) need to be able to indicate the profile to which a certain piece of data (record describing an individual cultural object, or a whole dataset) belong.
33
Data publishers need to be able to serve different profiles of the same data via the same data publication channel (Web API)
34
Data consumers (intermediary aggregators, Europeana and DPLA, data consumers) need to be able to specify the profile they are interested in
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100