lido-v1.1-public-beta-schematron-rules.xsd 7.52 KB
Newer Older
mmarkus1's avatar
mmarkus1 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
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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
<?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>
                
                <sch:rule abstract="true" id="sch_MixedContentInfo">
                    <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>
                
                <sch:rule abstract="true" id="sch_pref">
                    <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>
                
                <sch:rule abstract="true" id="sch_alternate">                    
                    <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>
                
                <sch:rule abstract="true" id="sch_DateTime">
                    <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>

            <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>
                <sch:rule context="lido:resourceRepresentation" id="sch_IIIF_Measurements">
                    <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>

        </xs:appinfo>
    </xs:annotation>
</xs:schema>