Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Sign in
Toggle navigation
Menu
Open sidebar
LIDO
lido-development
Commits
e1eafb23
Commit
e1eafb23
authored
May 23, 2021
by
mmarkus1
Browse files
revise QA schematron rules by Marco
parent
23bab982
Pipeline
#198239
passed with stage
in 33 seconds
Changes
1
Pipelines
1
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>
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment