Skip to content

GitLab

Commit e1eafb23 authored by mmarkus1's avatar mmarkus1
Browse files

revise QA schematron rules by Marco

parent 23bab982
Pipeline #198239 passed with stage
in 33 seconds
Hide whitespace changes
Inline Side-by-side
1.1/lido-v1.1-public-beta-schematron-rules.xsd
View file @ e1eafb23
......@@ -26,91 +26,100 @@
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>
<!-- Additional rules for quality assurance. They use XSLT 2.0 features and are provided for additional
quality and compliance checks. These can be extended/modified to create application profiles. -->
<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">
Deprecation: 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>[Data Quality] @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="name($current)"/>
<sch:let name="parent" value="$current/.."/>
<sch:let name="lang" value="string($current/@xml:lang)"/>
<sch:let name="siblings" value="$parent/child::*[name(.) = $currentName and (string(@xml:lang) = $lang or not(@xml:lang or $current/@xml:lang))]"/>
<sch:report test="
(count($siblings) > 1) and
not($siblings/@lido:pref = 'preferred' or
$siblings/@lido:pref = 'http://terminology.lido-schema.org/pref/preferred' or
$siblings/@lido:pref = 'http://terminology.lido-schema.org/lido00169')
and
not($siblings/@lido:pref = 'alternative' and $siblings/@lido:pref = 'alternate' or
$siblings/@lido:pref = 'http://terminology.lido-schema.org/pref/alternative' or
$siblings/@lido:pref = 'http://terminology.lido-schema.org/lido00170')"
role="warn">
Quality: 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>[Data Quality] @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">
Quality: Use 'alternative' instead of 'alternate' in this context. Consider changing the attribute's value or using the corresponding LIDO terminology.
</sch:report>
</sch:rule>
</sch:pattern>
<sch:pattern>
<sch:title>[Data Quality] xs:dateTime Dates</sch:title>
<sch:p>Check if a given string complies to the ISO 8601 date convention, i.e.
an optional '-' to indicate CE or BCE date range followed by a minimum of
4 digits denoting the year in the proleptic Gregorian calendar, an optional 2-digit month,
an optional 2-digit day of month, an optional 'T' with a 2-digit hour (as 24-hour clock),
an optional 2-digit minute and seconds, and an optional time zone designation of either Z for UTC
or the timezone offset in hours:minutes. Omitting a timezone designation indicates using a
local time reference. A timestamp should be used for recording the recordMetadataDates.
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]){0,2})?([Z]|(([+-][01][0-9]))(:?[0-5][0-9]){0,1})?)$')">
Quality: The date provided in <sch:name/> should follow the pattern [-]YYYY[Y+][-MM[-DD[Thh[: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>
<sch:pattern>
<sch:title>[Data Quality] 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 abstract="true" id="sch_IIIF_Measurements">
<sch:assert role="warn"
test="
not((lido:resourceMeasurementsSet)
and (@lido:type='http://terminology.lido-schema.org/lido00911'
or @lido:type='http://terminology.lido-schema.org/lido00912'))"
> Quality: 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>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment