Commit fdd6efb9 authored by mrodzis's avatar mrodzis 🌿
Browse files

Merge branch 'feature/#33-readme' into 'develop'

Feature/#33 readme

Closes #33

See merge request lido/development!45
parents 4539fdee e559eb05
## LIDO version 1.1 DRAFT
Experimental Draft version of proposed elements/attributes to address issues with LIDO 1.0.
_Do no use in production_
Northern Branch
This is the branch for ongoing contributions from BaliLabs (53°58' North) and digiCULT (54°20' North).
# LIDO version 1.1 DRAFT
Experimental Draft version of proposed elements/attributes to address issues with LIDO 1.0.
**Do no use in production!**
## What's new in LIDO v1.1
### General
The schema is developed at The most recent draft version can be found at
For the development of LIDO v1.1 the following criteria for taking into account suggestions for changes and extensions have been defined:
* The suggestion requires modification of the schema, e.g. there is no way to express the information in the LIDO v1.0 schema.
* The suggestion is based upon a known use case from practical LIDO applications.
* The requirement is generic and in the scope of LIDO v1.0.
* The suggestion can be implemented in a backwards compatible way with LIDO v1.0.
### General changes
* The schema and the docs are provided in a single XSD document from which different outputs (HTML, PDF, parsed-down XSD [TBD]) are serialized.
* The schema docs are provided in a structured way as TEI elements as follows:
- the element description
- the element's label
- elements from other schemas to which the respective LIDO element is equivalent
- a note where a user can find more context about the element (this often refers to CDWA FULL, as LIDO elements are largely based on LIDO's predecessor CDWA Lite)
- recommended data values for controlled terms
- cross-links between LIDO elements
- though provided in the docs, the following aspect will not be serialized in the PDF and HTML: 'How to record', 'Notes' (both outdated and largely merged into the element description), CIDOC CRM equivalents (not compiled yet)
* We introduced Schematron as a second quality assurance mechanism. This is e.g. used to ensure that dates comply to the xs:dateTime requirements.
* Added the TEI header into the schema. *This solution is tentative, and the header is yet to be updated.*
* Each LIDO element/complexType/attribute is now referenceable by an ID. This ID is (in most cases) identical to its name and comes in handy for developing application profiles.
### New elements (and why they have been introduced)
**applicationProfile**: Serves as an identifier for a LIDO application profile which has been developed by an institution or project. Link:
**conceptElementsSet**: Increases the schema's modularity. Link:
**conceptMixedComplexType**: A complexType allowing both free text and the elements defined in conceptElementsSet. This complexType is used for elements that only allowed free text in LIDO v1.0 but should be controllable with conceptID(s) and term(s) in LIDO v1.1. Link:
**displayRelatedWork**: A display element displayRelatedWork for the relatedWorkSet allows for transferring specific relationship information for presentation purposes while for the actual relationship type element (lido:relatedWorkRelType) terms from the LIDO Terminology should be used. Link:
**displayRepository**: A free-text description for designation of the institution of custody and, possibly, a descriptive indication of the exact location of the object while for repositoryName and repositoryLocation authorities should be used. Link:
**eventObjectMeasurements**: Indicates the dimensions or other measurements of the object/work as determined with respect to the described event, for instance a part addition or removal. Link:
**mostNotableEvent**: Qualifies an eventSet as the most notable or significant event as designated by the describing institution. Link:
**objectDescriptionRights**: Allows for setting separate rights information for the object description. Link:
**objectMaterialsTechSet/objectMaterialsTechWrap**: Allows for materials/technique information (meant like a physical characteristic of the object) outside of events. Link:
**rightsHolderComplexType**: Increases the schema's modularity. rightsHolder doesn't have to be defined fully twice. Link:
**textAttributesSet**: Increases the schema's modularity. Link:
**vitalPlaceActor**: Allows for providing the birth/death/activity place of an actor. Link:
**owl:sameAs**: Introduced for all elements that have an actorComplexType, placeComplexType or legalBodyRefComplexType. It enables acquisitors to directly identify an entity via an LOD reference. OWL has been implemented as xs:any and been restricted by Schematron.
**skos:Concept**: Introduced for all elements with a concept(Mixed)ComplexType. This enables acquisitors to make an LOD reference for a term via SKOS. SKOS has been implemented as xs:any and been restricted by Schematron. Link:
### Changed content model
The following elements can contain free text only in LIDO v.1.0, but can also provide controlled terms (e.g. from authoritative data) as an alternative via conceptComplexType in LIDO v1.1:
* attributionQualifierActor
* extentActor
* extentMaterialsTech
* extentSubject
* genderActor
* measurementType
* measurementUnit
### Changed descriptions
Definitions have generally been renamed to 'description's since they aren't definitions in the Aristotelian sense. The following descriptions have been changed:
* lidoRecID
* subjectConcept
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