Commit 2a06b41a authored by mmarkus1's avatar mmarkus1
Browse files

delete lido 1.1 draft files

parent 5e5ee590
This diff is collapsed.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="" type="application/xml"
<?xml-model href="" type="application/xml"
<TEI xmlns=""
<title>LIDO v1.1 – Accompanying Document</title>
<author>Lindenthal, Jutta</author>
<author>Stein, Regine</author>
<author>Weidling, Michelle</author>
<publisher>German LIDO Working Group</publisher>
<p>Copyright 2020, German LIDO Working Group</p>
<licence target="">Creative Commons Attribution 4.0 International (CC BY 4.0)</licence>
<p>Born digital.</p>
<div xml:id="intro">
<head>LIDO v1.1 – Accompanying Document</head>
<!-- place the introductory text here. text can also be added after the listing below (e.g. a conclusion or some other
kind of outro). surround any new text block in tei:div elements. -->
<p>Here goes the text.</p>
<!-- This file imports the other accompanying documents via XInclude.
The serialization of this is handled during the serialization of the complete documentation. -->
<xi:include href="accompanying-document-terminology-recommendations" xpointer="terminology_recommendations"/>
This diff is collapsed.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:lido=""
xmlns:skos="" xmlns:tei=""
xmlns:xs="" xmlns:xml=""
targetNamespace="" elementFormDefault="qualified"
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 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 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 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.
<sch:ns uri="" prefix="lido"/>
<sch:ns uri="" prefix="owl"/>
<sch:ns uri="" prefix="skos"/>
<sch:title>Abstract Schematron rules for quality assurance</sch:title>
<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">
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: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')"
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: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, and, instead.
<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: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>
<sch:rule context="lido:objectMeasurementsSet" id="sch_objectMeasurementsSet">
<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: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"
(@type = '' or @type = '')
and not(lido:resourceMeasurementsSet)"
> Do not set lido:resourceMeasurementsSet when providing a IIIF resource.
Resource measurements are available in the resource's info.json.
This diff is collapsed.
This diff is collapsed.
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