GithubHelp home page GithubHelp logo

music-encoding / music-encoding Goto Github PK

View Code? Open in Web Editor NEW
205.0 37.0 66.0 183.19 MB

美 The Music Encoding Initiative schema and guidelines development repository

Home Page: https://music-encoding.org

License: Educational Community License v2.0

XSLT 80.26% XQuery 0.05% CSS 18.86% JavaScript 0.48% Python 0.36%
mei mei-schemas music-notation mei-encoding mei-source notation music-encoding mei-guidelines xml music-documents

music-encoding's Introduction

The Music Encoding Initiative

DOI GitHub release (with filter) GitHub Deploy Schema and Guidelines

The Music Encoding Initiative (MEI) is an open-source effort to define a system for encoding musical documents in a machine-readable structure. MEI brings together specialists from various music research communities, including technologists, librarians, historians, and theorists in a common effort to define best practices for representing a broad range of musical documents and structures. The results of these discussions are formalized in the MEI Source and customizations, a core set of rules for recording physical and intellectual characteristics of music notation documents expressed in TEI’s ODD language (One Document Does-it-all, cf. amongst others: Viglianti, 2019). As such, the MEI Source contains both, the specifications that can be compiled to schema formats for validating XML files, and documentation in prose, the MEI Guidelines, which provide detailed explanations of the components of the MEI model and best practices suggestions.

The MEI Source is not a schema in itself; rather, it can be used to build customized schemas, such as mei-CMN, mei-Mensural, mei-all, etc. (also see Customizing MEI). This repository already includes several customizations. While these can form an ideal starting point for creating your own customizations, you should also understand customization and building processes.

In this document, you will learn how to contribute to the development of MEI by building the schema and guidelines (you should also consider consulting the tutorial on "Understanding ODD"). For the pre-built schemas of the latest release of MEI, please consult the "schemas" section of the music-encoding website.

Structure of this repository

This repository contains all the source code of the MEI Schema and Guidelines:

  • .github: Configuration files for GitHub Actions workflows.
  • customizations: TEI ODD files that allow you to build customized MEI schemata.
  • source: Contains the source code, as expressed in TEI ODD. This includes the source code for the MEI Guidelines and the MEI schema modules.
  • submodules: A container for Git Submodules: third-party developments that are needed, e.g., for building this repository's contents, but which are not part of our codebase.
  • tests: Unit tests for the MEI Schemata.
  • utils: Helper scripts e.g. for compiling schemata and guidelines from this repository.

Important

For the sake of the continuous integration (CI) workflow, the build artifacts of the schemata and guidelines are no longer included in this repository, but are generated on every commit to the develop branch and automatically pushed to their dedicated repositories. For more information please see the section Additional Resources below.

Nevertheless, it is possible to build any customization locally in your working copy of this repository.

Validating MEI files against an MEI Schema

One of the core strengths of the MEI Schema is that it allows an individual to validate an MEI file against an XML Schema to ensure the MEI file conforms to expected encodings and behaviors. To validate an MEI file you need an XML validation engine. XML Authoring tools, such as oXygen, might have built-in validation tools. There are also several command line utilities, including xmllint and jing.

For example, you might validate an MEI file from the sample-encodings project using the xmllint command line tool:

xmllint --noout --relaxng schemata/mei-CMN.rng "sample-encodings/MEI 3.0/Music/Complete\ examples/Bach_Ein_festeBurg.mei"

Or, the same command using jing.

jing schemata/mei-CMN.rng "sample-encodings/MEI 3.0/Music/Complete\ examples/Bach_Ein_festeBurg.mei"

Customizing MEI

The MEI model may be customized to express and validate different types of music documents. Customizations are configured with individual ODD files. This repository already includes several customizations:

  • mei-CMN: Validates MEI files that express common Western music notation.
  • mei-Mensural: Validates MEI files that express white Mensural notation (will raise validation errors if elements like "measure" exist in the MEI encoding).
  • mei-Neumes: Validates MEI files that express Neume notation (like Mensural, will raise validation errors if elements that are not part of neume notation exist in an encoding.)
  • mei-all: The full MEI Schema. This is the most permissive customization of MEI.
  • mei-all_anyStart: A customization of mei-all, allowing every MEI element as the root element.
  • mei-basic: The purpose of mei-Basic is to serve as common ground for data interchange, both between projects using different profiles of MEI, and other encoding schemes

Why Customizations?

For those who are used to having a single DTD or W3C Schema to validate music notation encodings, the customization process may seem to be a complex way of arriving at a schema to validate music notation. However, customizations are a vital part of the expressive power of MEI, and when used to their full extent, can assist organizations in ensuring the integrity and validity of their data.

When designing a music encoding system there are many contradictory and non-standardized practices associated with writing music notation. Different repertoires may have extremely different ways of expressing pitch or rhythm; for example, rhythm in Mensural notation is incompatible with the later systems developed in common Western notation.

Most attempts at addressing this complexity restrict a schema to only a certain subset of music notation and do not attempt to accurately represent the semantics of music notation that falls outside of its defined scope. So, for example, a system designed for common Western notation that depends on the existence of measures, duration, note shapes, or even staves, cannot semantically represent notations that do not have these features.

The MEI takes a different approach. With the customization system, schemas may be generated from an existing ‘library’ of well-defined musical behaviors, but each behavior may be mixed and matched according to the needs of the notation. In this sense, the MEI source functions more as a ‘library’ of music encoding tools by which many different types of notation can be expressed and not just a single monolithic schema.

Building MEI

The build process of MEI can produce several artifacts, as listed below. Depending on what artifacts you want to build, the build system has to meet additional requirements.

Artifacts Technologies Tools
Compiled ODD XInclude, XSLT 3.0 Saxon HE with Xerces
Schemata XInclude, XSLT 3.0 Saxon HE with Xerces
Guidelines HTML XInclude, XSLT 3.0, MEI to SVG Saxon HE with Xerces, Verovio Toolkit
Guidelines PDF XInclude, XSLT 3.0, MEI to SVG, HTML to PDF Saxon HE with Xerces, Verovio Toolkit, Prince XML

While it is possible to build the artifacts with other tools, the above are tested and thus recommended. Moreover, we try to support the building process on the most common operating systems (Microsoft Windows, Apple macOS and Linux), and currently have the following documented ways of building the artifacts:

  • command line: If your build system meets the prerequisites as described in Building MEI on the command line, you can build the artifacts natively.
  • Docker: MEI maintains a Docker image that meets all the prerequisites and can be used for building the artifacts via the command line. How to use the Docker image is described in the README of the docker-mei repository.
  • oXygen XML Editor: When the command line is not your preferred tool and you do not want to build the Guidelines PDF, you might consider using alternative environments, such as Synchrosoft’s oXygen XML software family. A description of how to set up corresponding transformation scenarios can be found in Building MEI with oXygen XML Editor.

Additional Resources

A live version of the MEI Guidelines is available on the MEI Website in the ’Documentation‘ menu:

In addition to the source files for MEI in this repository, there are other useful resources in other MEI repositories. The prebuilt release and development versions of:

And moreover

Referenced Material

  • Viglianti, R. (2019). One Document Does-it-all (ODD): A language for documentation, schema generation, and customization from the Text Encoding Initiative. Symposium on Markup Vocabulary Customization, Washington, DC. https://doi.org/10.4242/BalisageVol24.Viglianti01

License

Copyright 2017-2023 by the Music Encoding Initiative (MEI) Board (formerly known as "MEI Council")

Licensed under the Educational Community License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://opensource.org/licenses/ECL-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

This is a derivative work based on earlier versions of the schema © 2001-2006 Perry Roland and the Rector and Visitors of the University of Virginia; licensed under the Educational Community License version 1.0.

CONTACT: [email protected]

music-encoding's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

music-encoding's Issues

better document @trans.diat and @trans.semi

From [email protected] on February 04, 2012 22:41:39

In the current documentation, it is not clear whether these attributes record the amount of transposition from concert pitch to the written pitch or from the written pitch to concert pitch. For example, on a staff for Bb clarinet should @trans.diat=1 or -1? Should @-trans.semi=2 or -2? A decision needs to be made and documentation expanded accordingly.

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=48

XSD needs to be updated

From [email protected] on December 05, 2011 17:56:10

What steps will reproduce the problem? 1. Validate following file with mei-all.rng:

<title>Validation Test</title> 1. Validate the same file with mei-all.xsd. What is the expected output? What do you see instead? It's expected that both the RNG and the XSD tell us the document is valid, but the XSD insists on @-xml:id everywhere.

An XSD freshly generated by Roma fixes the problem.

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=41

Add model.titlePagePart

From [email protected] on September 28, 2011 19:10:40

In order to more closely match TEI and to make it easier to modify the content of the titlePage element, create a new model.titlePagePart class. Members of this class will be model.textcomponentLike, model.milestoneLike.txt, and, in order to allow graphic elements between components, model.graphicLike. More TEI-like title page components may be added by adding new elements and modifying the membership of model.titlePagePart.

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=36

Revise handling of metadata

From [email protected] on September 13, 2011 13:46:14

In order to encourage richer metadata encoding and facilitate conversion of metadata from other formats to MEI, several revisions/additions are required --

  1. use @accid on key instead of @-accid.ges
  2. restrict content model of to prevent confusion with
  3. add to model of ; revise description of
  4. allow in macro.workPart
  5. create new element for metadata use; add it to macro.workPart
    (this could perhaps be added later to scoreDef and staffDef as a substitute for meter.* attributes, similar to the way substitutes for clef.* attributes)
  6. permit multiple elements in model of
  7. add element; revise content model of
  8. add description and revise content model of
  9. revise description and content model of
  10. revise description of
  11. make a member of att.pointing; revise description of

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=31

Move module declarations into the encoded file

From andrew.hankinson on September 21, 2011 16:02:53

From an e-mail to the development mailing list, September 21 2011. Filed for future reference.

I wanted to put forward a crazy, wild, out-there idea to address something mentioned by Johannes in his most recent message:

"I also like the idea to have a defined pointer to the ODD, although the schema referenced by the XML instance is probably the better place for this. Roma already outputs a comment on when the schema was generated, maybe we could request to include a pointer to the source and modification files as well?"

What if, instead of a pointer to the ODD/RNG schema that we actually collapsed the customization into the encoded document itself, and declared what modules a given MEI file was using.

I see this as something like "include" or "import" statements present in most programming languages. We would still use Roma to process and generate a validation schema, but instead of being generated from a separate customization file we generate it from the file itself. Then the encoded file becomes self-descriptive for what features it supports.

Note that I'm aware of the self-referential problem this poses, namely "I'm correct because I say I'm correct." But, I would argue that if we're distributing the core MEI schema to developers and other encoders we already have a reference platform. If I make changes to the core MEI Schema and then attempt to distribute my encoded files they will not validate against anyone else's core.

Technically, not much would need to change. Roma (or something Roma-like) would need to be modified to read in a source and an actual encoding file, but it would still be generating a RelaxNG schema.

If we did want to deliver something "closed," we would still have the option of omitting the module declarations and simply providing a validation URL for a pre-generated RelaxNG schema, much like we do now.

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=32

transition to URI redux

From [email protected] on August 22, 2011 17:54:51

My fix for issue no. 1 introduced new confusion with regard to the use of the plist attribute.

Proposed fix:

  1. rename att.targets class back to att.plist
  2. add target attribute (allowing multiple URLs) to att.pointing class

Members of att.plist will be att.controlevent, annot, and expansion. These elements use @Plist (which may contain one or more URIs) to identify participants in the named structure. For instance, @Plist on annot is used to identify the elements to which the annotation pertains. It is important to be clear -- these elements are not targets of the annotation, but rather are gathered by the annotation. They may be also thought of as starting points for a relationship between them and the annotation.

Members of att.pointing will be avFile, barLine, bibl, contents, ending, graphic, lem, measure, pb, ptr, ref, rdg, and section. These elements use @target to identify the destination of a reference. Although it will usually contain a single URI (often identifying an external entity), @target may contain one or more URI references. However, it may sometimes be useful for @target to contain multiple URIs in order to implement a one-to-many relationship between the element carrying the attribute and the URIs given in @target.

Many-to-many relationships may be implemented by making an element a member of both att.plist and att.pointing classes. In this case, @Plist will contain references to the starting points and @target will hold the ending points of the relationship.

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=7

Remove group element

From [email protected] on September 29, 2011 11:45:58

With recent changes to the meiHead element; that is, adding relatedItem, replacing profileDesc with workDesc that can contain multiple work elements, and providing the decls attribute that allows "chunks" of transcription to be associated with "chunks" of metadata, the group element is no longer needed in order to support composite texts, such as anthologies, collections, etc.

Each unit in a composite text can be marked as an and associated with its corresponding relatedItem or work metadata via @-decls. The hierarchy of relatedItem elements and mdiv elements will mirror each other. For example, in the simple case --

Because both relatedItem and mdiv can be nested recursively, more complex cases can also be supported by the same method. For example --

The structure of will (always?) have the same number of hierarchical levels as , making it easier to comprehend the data-metadata associations.

meiCorpus will be retained for the gathering of full MEI documents into a single file.

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=37

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.