lido-qa.xsd 8.3 KB
Newer Older
mrodzis's avatar
mrodzis committed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:lido="http://www.lido-schema.org"
    xmlns:lido-qa="http://www.lido-schema.org/quality-assurance"
    xmlns:sch="http://purl.oclc.org/dsdl/schematron"
    xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:tei="http://www.tei-c.org/ns/1.0"
    xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xml="http://www.w3.org/XML/1998/namespace"
    targetNamespace="http://www.lido-schema.org/quality-assurance" elementFormDefault="qualified"
    attributeFormDefault="qualified">
    <!--
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        xx This is an additional schema for LIDO v1.1. It is to be understood as complementary tool for
        xx assuring the quality of LIDO records. This means it is not obligatory to use this schema when
        xx validating your files; some rules, however, will warn you about changes in the upcoming LIDO v2.0
        xx which are not backwards compatible.
        xx
        xx This document implements the Schematron error roles as follows::
        xx * "info":    highlights elements which will be deprecated in the next LIDO version
        xx * "warn":    points out data values or elements that are correct according to the LIDO schema but
        xx              could/should be improved
        xx
        xx Prepared for CIDOC Working Group Data Harvesting and Interchange, CDWA Lite/museumdat Working Group,
        xx Collections Trust and Deutscher Museumsbund - Fachgruppe Dokumentation by:
        xx Michelle Weidling – Niedersaechsische Staats- und Universitaetsbiblithek Goettingen
        xx
        xx Copyright (c) 2020 ICOM-CIDOC for the Data Harvesting and Interchange Working Group.
        xx These are licensed under the Creative Commens Attribution 4.0 International (CC BY 4.0) license.
        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    -->
    
    <xs:annotation>
        <xs:appinfo>
            <sch:ns uri="http://www.lido-schema.org" prefix="lido"/>
            <sch:ns uri="http://www.w3.org/2002/07/owl#" prefix="owl"/>
            <sch:ns uri="http://www.w3.org/2004/02/skos/core#" prefix="skos"/>
            
            <sch:title>Abstract Schematron rules for quality assurance</sch:title>
            <sch:pattern>
                <sch:title>Deprecation Warning: Controlled vocabulary instead of free text</sch:title>
                <sch:p>In upcoming versions of LIDO some element won't allow for free text anymore but will require terms
                taken from a (local) controlled vocabulary. This should improve the interoperability of the data and recall rates
                in aggregating web services.</sch:p>
                
43
                <sch:rule abstract="true" id="sch_MixedContentInfo">
mrodzis's avatar
mrodzis committed
44
45
46
47
48
49
50
51
52
53
54
55
56
57
                    <sch:report
                        test="text()[matches(., '[\w]')]" role="info">
                        In upcoming versions of LIDO <sch:name/> will only allow for skos:Concept, lido:conceptID and lido:term as child elements.
                        The use of free text will be deprecated.
                    </sch:report>
                </sch:rule>
            </sch:pattern>
            
            <sch:pattern>
                <sch:title>@pref: Discern preferred and alternative elements</sch:title>
                <sch:p>If there is more than one element holding a @pref, alternatives as well as the preferred element should be indicated.
                This isn't stated clearly in the LIDO v1.0 schema documentation but should be kept in mind when indexing objects; otherwise the preferred
                variant might be unclear to a data user. Also, omitting this attribute contradicts international best practices for retrieval quality.</sch:p>
                
58
                <sch:rule abstract="true" id="sch_pref">
mrodzis's avatar
mrodzis committed
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
                    <sch:let name="current" value="current()"/>
                    <sch:let name="currentName" value="$current/name()"/>
                    <sch:let name="parent" value="$current/.."/>
                    <sch:let name="lang" value="$current/@xml:lang/string()"/>
                    <sch:let name="siblings" value="$parent/child::*[name(.) = $currentName and (@xml:lang/string() = $lang or not(@xml:lang or $current/@xml:lang))]"/>
                    
                    <sch:report test="
                        count($siblings) gt 1 and
                        not($siblings/@lido:pref = 'preferred') and
                        not($siblings/@lido:pref = 'alternative' and $siblings/@lido:pref = 'alternate')"
                        role="warn">
                        When providing more than one <sch:name/> the preferred and alternative variant(s) should be cleary marked as such via @pref.
                    </sch:report>
                </sch:rule>
            </sch:pattern>
            
            <sch:pattern>
                <sch:title>@pref: "alternative" instead of "alternate"</sch:title>
                <sch:p>LIDO v1.0 falsely suggests the value 'alternate' for the pref attribute. It is established to use 'alternative' in this context.</sch:p>
                
79
                <sch:rule abstract="true" id="sch_alternate">                    
mrodzis's avatar
mrodzis committed
80
81
82
83
84
85
86
87
88
89
90
91
                    <sch:report test="@lido:pref = 'alternate'" role="warn">
                        It is established to use 'alternative' instead of 'alternate' in this context. Consider changing the attribute's value or using the corresponding
                        LIDO terminology, http://terminology.lido-schema.org/pref and http://terminology.lido-schema.org/alternative, instead.
                    </sch:report>
                </sch:rule>
            </sch:pattern>
            
            <sch:pattern>
                <sch:title>xs:dateTime Dates</sch:title>
                <sch:p>Check if a given string complies to the ISO 8601 date convention. This pattern is used for
                    the cases where an element allows for xs:string in LIDO v1.0 while providing a date.</sch:p>
                
92
                <sch:rule abstract="true" id="sch_DateTime">
mrodzis's avatar
mrodzis committed
93
94
95
96
97
                    <sch:assert role="warn" test="matches(., '-?[0-9]{4}-(0[1-9]|1[12])-([0][1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3])(:[0-5][0-9]){2}(Z|(\+|\-)(0[0-9]|1[12])(:[0-5][0-9])?)')">
                        The date provided in <sch:name/> should comply to the format [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm].
                    </sch:assert>
                </sch:rule>
            </sch:pattern>
98
99
100
101
102
103
            
            <sch:pattern>
                <sch:title>@lido:type for objectMeasurementsSetComplexType</sch:title>
                <sch:p>Although the lido:type has been introduced for lido:objectMeasurementsSetComplexType, it should only be used for
                    lido:eventObjectMeasurementsSet in context of the EODEM application profile.</sch:p>
                
mrodzis's avatar
mrodzis committed
104
                <sch:rule context="lido:objectMeasurementsSet" id="sch_objectMeasurementsSet">
105
106
107
108
109
                    <sch:assert role="warn" test="not(@lido:type)">
                        The only element of the complex type lido:objectMeasurementsSetComplexType holding @lido:type should be lido:eventObjectMeasurementsSet.
                    </sch:assert>
                </sch:rule>
            </sch:pattern>
110
111
112
113
114
115

            <sch:pattern>
                <sch:title>Avoid Providing Resource Measurements When Using IIIF</sch:title>
                <sch:p>IIIF resources provide information about their measurements in their
                    info.json. Therefore it is redundant to also make the resource's measurements
                    available in lido:resourceMeasurementsSet.</sch:p>
116
                <sch:rule context="lido:resourceRepresentation" id="sch_IIIF_Measurements">
117
118
119
120
121
122
123
124
125
126
                    <sch:assert role="warn"
                        test="
                            (@type = 'http://terminology.lido-schema.org/lido00911' or @type = 'http://terminology.lido-schema.org/lido00912')
                            and not(lido:resourceMeasurementsSet)"
                        > Do not set lido:resourceMeasurementsSet when providing a IIIF resource.
                        Resource measurements are available in the resource's info.json.
                    </sch:assert>
                </sch:rule>
            </sch:pattern>

mrodzis's avatar
mrodzis committed
127
128
129
        </xs:appinfo>
    </xs:annotation>
</xs:schema>