Dear Gitlab users, due to maintenance reasons, Gitlab will not be available on Thursday 30.09.2021 from 5:00 pm to approximately 5:30 pm.

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
...@@ -26,91 +26,100 @@ ...@@ -26,91 +26,100 @@
xx These are licensed under the Creative Commens Attribution 4.0 International (CC BY 4.0) license. xx These are licensed under the Creative Commens Attribution 4.0 International (CC BY 4.0) license.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--> -->
<xs:annotation> <xs:annotation>
<xs:appinfo> <xs:appinfo>
<sch:ns uri="http://www.lido-schema.org" prefix="lido"/> <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/2002/07/owl#" prefix="owl"/>
<sch:ns uri="http://www.w3.org/2004/02/skos/core#" prefix="skos"/> <sch:ns uri="http://www.w3.org/2004/02/skos/core#" prefix="skos"/>
<sch:title>Abstract Schematron rules for quality assurance</sch:title> <sch:title>Abstract Schematron rules for quality assurance</sch:title>
<sch:pattern> <!-- Additional rules for quality assurance. They use XSLT 2.0 features and are provided for additional
<sch:title>Deprecation Warning: Controlled vocabulary instead of free text</sch:title> quality and compliance checks. These can be extended/modified to create application profiles. -->
<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 <sch:pattern>
in aggregating web services.</sch:p> <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
<sch:rule abstract="true" id="sch_MixedContentInfo"> taken from a (local) controlled vocabulary. This should improve the interoperability of the data and recall rates
<sch:report in aggregating web services.</sch:p>
test="text()[matches(., '[\w]')]" role="info"> <sch:rule abstract="true" id="sch_MixedContentInfo">
In upcoming versions of LIDO <sch:name/> will only allow for skos:Concept, lido:conceptID and lido:term as child elements. <sch:report
The use of free text will be deprecated. test="text()[matches(., '[\w]')]" role="info">
</sch:report> Deprecation: In upcoming versions of LIDO <sch:name/> will only allow for skos:Concept, lido:conceptID and lido:term as child elements.
</sch:rule> The use of free text will be deprecated.
</sch:pattern> </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. <sch:pattern>
This isn't stated clearly in the LIDO v1.0 schema documentation but should be kept in mind when indexing objects; otherwise the preferred <sch:title>[Data Quality] @pref: Discern preferred and alternative elements</sch:title>
variant might be unclear to a data user. Also, omitting this attribute contradicts international best practices for retrieval quality.</sch:p> <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
<sch:rule abstract="true" id="sch_pref"> variant might be unclear to a data user. Also, omitting this attribute contradicts international best practices for retrieval quality.</sch:p>
<sch:let name="current" value="current()"/> <sch:rule abstract="true" id="sch_pref">
<sch:let name="currentName" value="$current/name()"/> <sch:let name="current" value="current()"/>
<sch:let name="parent" value="$current/.."/> <sch:let name="currentName" value="name($current)"/>
<sch:let name="lang" value="$current/@xml:lang/string()"/> <sch:let name="parent" value="$current/.."/>
<sch:let name="siblings" value="$parent/child::*[name(.) = $currentName and (@xml:lang/string() = $lang or not(@xml:lang or $current/@xml:lang))]"/> <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=" <sch:report test="
count($siblings) gt 1 and (count($siblings) > 1) and
not($siblings/@lido:pref = 'preferred') and not($siblings/@lido:pref = 'preferred' or
not($siblings/@lido:pref = 'alternative' and $siblings/@lido:pref = 'alternate')" $siblings/@lido:pref = 'http://terminology.lido-schema.org/pref/preferred' or
role="warn"> $siblings/@lido:pref = 'http://terminology.lido-schema.org/lido00169')
When providing more than one <sch:name/> the preferred and alternative variant(s) should be cleary marked as such via @pref. and
</sch:report> not($siblings/@lido:pref = 'alternative' and $siblings/@lido:pref = 'alternate' or
</sch:rule> $siblings/@lido:pref = 'http://terminology.lido-schema.org/pref/alternative' or
</sch:pattern> $siblings/@lido:pref = 'http://terminology.lido-schema.org/lido00170')"
role="warn">
<sch:pattern> Quality: When providing more than one <sch:name/> the preferred and alternative variant(s) should be cleary marked as such via @pref.
<sch:title>@pref: "alternative" instead of "alternate"</sch:title> </sch:report>
<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>
</sch:pattern>
<sch:rule abstract="true" id="sch_alternate">
<sch:report test="@lido:pref = 'alternate'" role="warn"> <sch:pattern>
It is established to use 'alternative' instead of 'alternate' in this context. Consider changing the attribute's value or using the corresponding <sch:title>[Data Quality] @pref: "alternative" instead of "alternate"</sch:title>
LIDO terminology, http://terminology.lido-schema.org/pref and http://terminology.lido-schema.org/alternative, instead. <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:report> <sch:rule abstract="true" id="sch_alternate">
</sch:rule> <sch:report test="@lido:pref = 'alternate'" role="warn">
</sch:pattern> Quality: Use 'alternative' instead of 'alternate' in this context. Consider changing the attribute's value or using the corresponding LIDO terminology.
</sch:report>
<sch:pattern> </sch:rule>
<sch:title>xs:dateTime Dates</sch:title> </sch:pattern>
<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:pattern>
<sch:title>[Data Quality] xs:dateTime Dates</sch:title>
<sch:rule abstract="true" id="sch_DateTime"> <sch:p>Check if a given string complies to the ISO 8601 date convention, i.e.
<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])?)')"> an optional '-' to indicate CE or BCE date range followed by a minimum of
The date provided in <sch:name/> should comply to the format [-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm]. 4 digits denoting the year in the proleptic Gregorian calendar, an optional 2-digit month,
</sch:assert> an optional 2-digit day of month, an optional 'T' with a 2-digit hour (as 24-hour clock),
</sch:rule> an optional 2-digit minute and seconds, and an optional time zone designation of either Z for UTC
</sch:pattern> 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:pattern>
<sch:title>Avoid Providing Resource Measurements When Using IIIF</sch:title> <sch:title>[Data Quality] Avoid Providing Resource Measurements When Using IIIF</sch:title>
<sch:p>IIIF resources provide information about their measurements in their <sch:p>IIIF resources provide information about their measurements in their
info.json. Therefore it is redundant to also make the resource's measurements info.json. Therefore it is redundant to also make the resource's measurements
available in lido:resourceMeasurementsSet.</sch:p> available in lido:resourceMeasurementsSet.</sch:p>
<sch:rule context="lido:resourceRepresentation" id="sch_IIIF_Measurements"> <sch:rule abstract="true" id="sch_IIIF_Measurements">
<sch:assert role="warn" <sch:assert role="warn"
test=" test="
(@type = 'http://terminology.lido-schema.org/lido00911' or @type = 'http://terminology.lido-schema.org/lido00912') not((lido:resourceMeasurementsSet)
and not(lido:resourceMeasurementsSet)" and (@lido:type='http://terminology.lido-schema.org/lido00911'
> Do not set lido:resourceMeasurementsSet when providing a IIIF resource. or @lido:type='http://terminology.lido-schema.org/lido00912'))"
Resource measurements are available in the resource's info.json. > Quality: Do not set lido:resourceMeasurementsSet when providing a IIIF resource.
</sch:assert> Resource measurements are available in the resource's info.json.
</sch:rule> </sch:assert>
</sch:pattern> </sch:rule>
</sch:pattern>
</xs:appinfo> </xs:appinfo>
</xs:annotation> </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