Basic Concepts for Genealogical Standards

FHISO's Basic Concepts for Genealogical Standards standard defines various low-level concepts that will be used in many FHISO standards, and whose definitions do not logically belong in any one particular higher-level standard.

The definition of a string which is used in multiple FHISO standards is given in §2 of this standard, together with various related concepts such as characters and whitespace, and §3 defines briefly how FHISO standards use language tags. Terms are defined in §4 as a form of extensible identifier using IRIs, and §4.1 discusses information that may be retrieved from these IRIs. The notion of a datatype is defined in §6, which also includes details on how to specify a new datatype.

The concepts of a classes and properties are defined in §5. They provide an infrastructure for defining extensions to FHISO standards and new, compatible standards in such a way that applications can use a discovery mechanism to find out about unknown components, allowing them to be processed. The facilities in these sections will primarily be of use to parties defining extensions or implementing discovery.

Conventions used

Where this standard gives a specific technical meaning to a word or phrase, that word or phrase is formatted in bold text in its initial definition, and in italics when used elsewhere. The key words must, must not, required, shall, shall not, should, should not, recommended, not recommended, may and optional in this standard are to be interpreted as described in [RFC 2119].

An application is conformant with this standard if and only if it obeys all the requirements and prohibitions contained in this document, as indicated by use of the words must, must not, required, shall and shall not, and the relevant parts of its normative references. Standards referencing this standard must not loosen any of the requirements and prohibitions made by this standard, nor place additional requirements or prohibitions on the constructs defined herein.

If a conformant application encounters data that does not conform to this standard, it may issue a warning or error message, and may terminate processing of the document or data fragment.

Indented text in grey or coloured boxes does not form a normative part of this standard, and is labelled as either an example or a note.

The grammar given here uses the form of EBNF notation defined in §6 of [XML], except that no significance is attached to the capitalisation of grammar symbols. Conforming applications must not generate data not conforming to the syntax given here, but non-conforming syntax may be accepted and processed by a conforming application in an implementation-defined manner.

This standard uses prefix notation, as defined in §4.3 of this standard, when discussing specific terms. The following prefix bindings are assumed in this standard:

Characters and strings

Characters are specified by reference to their code point number in [ISO 10646], without regard to any particular character encoding. In this standard, characters may be identified in this standard by their hexadecimal code point prefixed with "U+".

Characters must match the Char production from [XML].

Char  ::=  [#1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

A string is a sequence of zero or more characters, and should only be used to encode textual data.

Applications may convert any string into Unicode Normalization Form C, as defined in any version of Unicode Standard Annex #15 [UAX 15].

Characters matching the RestrictedChar production from [XML] should not appear in strings, and applications may process such characters in an implementation-defined manner or reject strings containing them.

RestrictedChar  ::=  [#x1-#x8] | [#xB-#xC] | [#xE-#x1F]
                       | [#x7F-#x84] | [#x86-#x9F]

Conformant applications must be able to store and process strings containing arbitrary characters other than those matching the RestrictedChar. In particular, applications must be able to handle characters which correspond to unassigned Unicode code points as they may be assigned in future versions of [ISO 10646]. Applications must also be able to handle characters outside Unicode's Basic Multilingual Plane — that is, characters with a code point of U+10000 or higher.

Whitespace is defined as a sequence of one or more space characters, carriage returns, line feeds, or tabs. It matches the production S from [XML].

S  ::=  (#x20 | #x9 | #xD | #xA)+

Whitespace normalisation is the process of discarding any leading or trailing whitespace, and replacing other whitespace with a single space (U+0020) character.

In the event of a difference between the definitions of the Char, RestrictedChar and S productions given here and those in [XML], the definitions in the latest edition of XML 1.1 specification are definitive.

Language tags

A language tag is a string that is used to represent a human language, and where appropriate the script and regional variant or dialect used. They are commonly used to tag other strings to identify their language in a machine-readable manner.

The language tag shall match the Language-Tag production from [RFC 5646], or from any future RFC published by the IEFT that obsoletes [RFC 5646] (hereinafter referred to as RFC 5646's successor RFC), and should be valid, as defined in §2.2.9 of [RFC 5646].

Valid language tags have the meaning that is assigned to them by [RFC 5646] and any successor RFC. Applications may discard any language tag that is not well-formed and replace it with und, meaning a undetermined language, but must not discard any language tag that is well-formed even if it is not valid.

A conformant application may convert any language tag into its canonical form, as defined by §4.5 of [RFC 5646] or an equivalent section of a successor RFC.

A conformant application may alter a language tag in any other way that leaves its canonical form unchanged when compared in a case-insensitive manner.

A string which is accompanied by a language tag which identifies the language in which the string is written is called a language-tagged string.

Terms

A term is a form of identifier used in FHISO standards to represent a concept which it is useful to be able to reference. A term consists of a unique, machine-readable identifier, known as the term name, paired with a clearly-defined meaning for the concept or idea that it represents. Term names shall take the form of an IRI matching the IRI production in §2.2 of [RFC 3987].

http://www.w3.org/2001/XMLSchema#integer

Term names are compared using the "simple string comparison" algorithm given in §5.3.1 of [RFC 3987]. If a term name does not compare equal to an IRI known to the application, the application must not make any assumptions about the term, its meaning or intended use, based on the form of the IRI or any similarity to other IRIs.

https://éléments.example.com/nationalité
HTTPS://ÉLÉMENTS.EXAMPLE.COM/nationalit%C3%A9
https://xn--lments-9uab.example.com/nationalit%c3%a9

An IRI must not be used as a term name unless it can be converted to a URI using the algorithm specified in §3.1 of [RFC 3987], and back to a IRI again using the algorithm specified in §3.2 of [RFC 3987], to yield the original IRI.

The terms defined in FHISO standards all have term names that begin https://terms.fhiso.org/. Subject to the requirements in the applicable standards, third parties may also define additional terms. It is recommended that any such terms use either the http or preferably the https IRI scheme defined in §2.7.1 and §2.7.2 of [RFC 7230] respectively, and an authority component consisting of just a domain name or subdomain under the control of the party defining the term.

IRI resolution

It is recommended that an HTTP GET request to a term name IRI with an http or https scheme (once converted to a URI per §4.1 of [RFC 3987]), should result in a 303 "See Other" redirect to a document containing a human-readable definition of the term if the request was made without an Accept header or with an Accept header matching the format of the human-readable definition. It is further recommended that this format should be HTML, and that documentation in alternative formats may be made available via HTTP content negotiation when the request includes a suitable Accept header, per §5.3.2 of [RFC 7231].

Parties defining terms should arrange for their term name to support discovery. This when an HTTP GET request to a term name IRI with an http or https scheme, made with an appropriate Accept header, yields 303 redirect to a machine-readable definition of the term.

This standard does not define a discovery mechanism, but it is recommended that parties defining terms support FHISO's [Triples Discovery] mechanism, and may additionally support other mechanisms. Support for discovery by applications is optional.

GET /events/Baptism HTTP/1.1
Host: example.com
Accept: application/n-triples, application/x-discovery; q=0.9

HTTP/1.1 303 See Other
Location: https://example.com/events/Baptism.n3
Vary: Accept

GET /events/Baptism.n3 HTTP/1.1
Host: example.com
Accept: application/n-triples, application/x-discovery; q=0.9

A party defining a term may support discovery without using HTTP content negotiation on their web server by serving a machine-readable definition of the term unconditionally (which should be served via a 303 redirect), however it is recommended that such servers implement HTTP content negotiation respecting the Accept header.

Namespaces

The namespace of a term is another term which identifies a collection of related terms defined by the same party. The term name of the namespace is also referred to as its namespace name. The namespace name of the namespace of some term is found as follows.

If the term name ends with a non-empty fragment identifier, then its namespace name is formed by removing the fragment identifier, leaving an IRI ending with a #.

http://www.w3.org/2001/XMLSchema#integer

http://www.w3.org/2001/XMLSchema#

Otherwise, if the term name ends with a non-empty path segment, then its namespace name is formed by removing the path segment, leaving an IRI ending with a /.

https://terms.fhiso.org/types/pattern

https://terms.fhiso.org/types/

Otherwise, the namespace is undefined.

Prefix notation

Term names are sometimes referred using prefix notation. This is a system whereby prefixes are assigned to namespace names which occur frequently in term names. Then, instead of writing the term name in full, the leading portion of the term name equal to the namespace name is replaced by its prefix followed by a colon (U+003A) separator.

Underlying type system

Classes

Terms are used in many contexts in FHISO standards and it can be useful to have a concise, machine-readable way of stating the use for which it was defined.

A class is a term used to denote a particular context or use for which other terms may be defined. Standards defining such contexts should define a class to represent that context, and must do so if the third parties are permitted to define their own terms for use in that context.

https://example.com/events/Baptism  
https://example.com/events/Ordination
https://example.com/events/Emigration
https://example.com/events/Death

https://example.com/events/EventType

The term name of a class is also referred to as its class name.

The type of a term

When a term has been defined for use in the context denoted by some class, that class is referred to as the type of the term.

The type of a term is a piece of information which must be provided, perhaps implicitly, when defining a term. As such, the type is a property of the term, as defined in §5.2, and needs a property term to represent it. This standard uses the rdf:type term for this purpose:

The class of classes

As a class is a term, defining a class is itself a context in which terms are defined, including by third parties. This means the general concept of a class needs a term defining to represent it. This standard uses the rdfs:Class term for this purpose:

The type of any class is therefore rdfs:Class.

Subclasses

A class may be defined as a subclass of another class. The latter class is referred to as the superclass of the former class. The subclass denotes a more specialised version of the context denoted by its superclass. A term whose type is subclass of some other class may be used wherever a term is required whose type is the superclass.

The superclass of a class must be specified when defining a class to be the subclass of some other class. As such, the superclass of the class is a property of the class, as defined in §5.2 and needs a property term to represent it. This standard uses the rdfs:subClassOf term for this purpose:

The notion of a subclass is transitive, meaning that if a class is a subclass of a second class, and that second class is a subclass of a third class, then the first class is a subclass of the third. The notion of a subclass is also reflexive, meaning that a class is by definition a subclass of itself. The notion of a superclass is similarly transitive and reflexive.

The rdfs:subClassOf property is defined as a required property of rdfs:Class, meaning its supertypes must be specified whenever a new class is defined. However this standard does not require every superclass to be identified explicitly. If a class has two or more superclasses, and one of the superclasses is itself a superclass of another of the superclasses, then the superclass of the superclass need not be identified explicitly.

The universal superclass

This standard uses rdfs:Resource as the universal superclass defined to be the superclass of all classes.

This class has no semantics of its own, other than to be class of all things that can be expressed in this data model.

Properties

During discovery, and in other situations when a formal definition of a particular term is needed, it is necessary to have a formalism for providing information about that term.

A property is a particular piece of information that might be provided when defining some entity. The thing being defined is typically a term, and is called the subject of the property.

The property consists of two parts, both of which are required to be present:

• a property name, which identifies the nature of the information in the property; and
• a property value, which contains the data about the subject of the property.

The property name shall be a term that has been defined to be used as a property name in the manner required by this standard; a term defined for this purpose is called a property term.

The property value shall be a term, a string, or a language-tagged string. The property value may additionally be tagged with a datatype name, which is a term name defined in §6.

Properties shall not have default property values that applies when the property is absent, however standards may define how an conformant application handles the absence of a property.

Standards which introduce such pieces of information should define a property terms to represent them, and must do so if third parties are permitted to define their own terms and if it is recommended or required that these third parties document or otherwise make available the information represented by the property.

https://example.com/events/cardinality

The term name of a property term is also referred to as its property term name.

The class of property terms has the following class name:

Range

The range of a property term is a formal specification of allowable property values for a property whose property name is that property term. The range shall be a class name or a datatype name.

When the range is a class, the property value shall be a term whose type is that class; when the range is a datatype, the value associated with the property shall be a string in the lexical space of that datatype.

https://example.com/events/SinglyOccurring
https://example.com/events/MultiplyOccurring

https://example.com/events/Cardinality

https://example.com/events/Cardinality

Standards which define property terms should specify their range, and must do so if third parties are permitted to define their own terms and if it is recommended or required that these third parties document or otherwise make available the information represented by the property term.

The range of a property term is itself a property which is defined as follows:

Required properties

A property which must be provided when a third party defining a new term with some particular type is called a required property.

The type of a new term being defined is a class, and therefore the list of the property names of the required properties of a term defined with that type is a property of that class. The property representing the required properties of a class is defined as follows:

The required properties of a class shall include all the required properties of each superclass of the class.

Datatypes

A datatype is a term which serves as a formal description of the values that are permissible in a particular context. Being a term, a datatype is identified by a term name which is an IRI. The term name of a datatype is also referred to as its datatype name.

A datatype has a lexical space which is the set of strings which are interpreted as valid values of the datatype. The definition of a datatype shall state how each string in its lexical space maps to a logical value, and state the semantics associated with of those values.

The mapping from lexical representations to logical values need not be one-to-one. If a datatype has multiple lexical representations of the same logical value, a conformant application must treat these representations equivalently and may change a string of that datatype to be a different but equivalent lexical representation.

Strings outside the lexical space of a datatype must not be used where a string of that datatype is required. If an application encounters any such strings, it may remove them from the dataset or may convert them to a valid value in an implementation-defined manner. Any such conversion that is applied automatically by an application must either be locale-neutral or respect any locale given in the dataset.

This standard uses the rdfs:Datatype class as the class of datatypes, defined as follows:

Patterns

A party defining a datatype shall specify a pattern for that datatype. This is a regular expression which provides a constraint on the lexical space of the datatype. Matching the pattern might not be sufficient to validate a string as being in the lexical space of the datatype, but parties defining a datatype must ensure that all strings in the lexical space match the pattern, even if some strings outside the lexical space also match the pattern.

-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])
(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))? 

The property term representing the pattern of a datatype is defined as follows:

A datatype with a pattern other than ".*" is known as a structured datatype, while one with a pattern of ".*" is known as an unstructured datatype.

Subtypes

A datatype may be defined as a subtype of one or more other datatype which are referred to as its supertypes. This is used to provide a more specific version of a more general datatype. If an application is unfamiliar with the subtype it may process it as if it were one of its supertypes. The subtype must be defined in such a way that at most this results in some loss of meaning but does not introduce any false implications about the dataset.

The lexical space of the subtype shall be a subset of the lexical space of the supertype.

All datatypes are implicitly a subtype of the xsd:anyAtomicType abstract datatype defined to be the universal supertype in §6.6.6.

The notion of a subtype is transitive, meaning that if a datatype is a subtype of a second datatype, and that second datatype is a subtype of a third datatype, then the first datatype is a subtype of the third. The notion of a subtype is also reflexive, meaning that a datatype is by definition a subtype of itself. The notion of a supertype is similarly transitive and reflexive.

Non-trivial supertypes {non-trivial-types}

The trivial supertypes of a datatype are certain supertypes whose status as a supertype of the datatype is implied by the data model defined in this standard. The trivial supertypes of a datatype include the datatype itself and the universal supertype, xsd:anyAtomicType. A supertype which not a trivial supertype is called a non-trivial supertype.

The property term representing a non-trivial supertype of a datatype is defined as follows:

The types:nonTrivialSupertype property must not be used to record a trivial supertypes of the datatype.

A types:nonTrivialSupertype property must be used to record every non-trivial supertype of a datatype which is not implied by the transitivity of types:nonTrivialSupertype and the other types:nonTrivialSupertype properties present.

As a way of checking for data integrity during discovery, an additional property is provided representing the number of non-trivial supertypes of the datatype that are either recorded using types:nonTrivialSupertype properties or are implied by them via transitivity:

This types:nonTrivialSupertypeCount property is a required property of rdfs:Datatype, and must be specified (with a value of "0") even if there are no non-trivial supertypes.

An application which finds out about a datatype through discovery must not assume it knows the supertypes of the datatype unless it has verified that the number of non-trivial supertypes specified with the types:nonTrivialSupertype property or implied by the transitivity of that property is equal to the value of the types:nonTrivialSupertypeCount property.

In the datatype definition tables in this standard, a single supertype row is given which is understood to contain a complete list of all non-trivial supertypes and no trivial supertypes.

Abstract datatypes

A datatype may be defined to be a abstract datatype. An abstract datatype is one that must only be used as a supertype of other types. A string must not be declared to have a datatype which is an abstract datatype. Abstract datatypes shall specify a pattern and shall have a lexical space.

The property that represents whether or not a datatype is an abstract datatype defined as follows:

Language-tagged datatypes

A language-tagged datatype is a datatype whose values are language-tagged strings consisting of both a string from the lexical space of the datatype and a language tag to identify the language in which that particular string is written.

Language-tagged datatypes should be used whenever a datatype is needed to represent textual data that is in a particular language or script and which cannot automatically be translated or transliterated as required, and should not be used otherwise.

https://terms.fhiso.org/sources/AgentName

Language-tagged datatypes shall define a pattern, just as other datatypes do.

A datatype that is not a language-tagged datatype is called a non-language-tagged datatype.

A language-tagged datatypes may be used as a supertype of a datatype. All subtypes of a language-tagged datatype shall also be language-tagged datatypes.

All language-tagged datatypes are implicitly a subtype of the rdf:langString datatype defined in §6.6.5.

Unions of datatypes

A union of datatypes is an abstract datatype which is defined in terms of a unordered list of two or more distinct datatypes called its constituent datatypes. The constituent datatypes must not themselves be unions of datatypes. The lexical space of a union of datatypes is the union of the lexical spaces of each constituent datatype.

Like any other datatype, a union of datatypes is a term with a term name. It must also specify a pattern.

https://terms.fhiso.org/dates/Date

http://www.w3.org/1999/02/22-rdf-syntax-ns#langString
https://terms.fhiso.org/dates/AbstractDate

A union of datatypes may contain language-tagged datatypes, non-language-tagged datatypes, or a mixture of both.

Each constituent datatype of a union of datatypes is a subtype of the union of datatypes. Whenever a union of datatypes is supertype of some other datatype it is defined to be a trivial datatype.

A datatype shall be a supertype of a union of datatypes if and only if it is a supertype of every constituent datatype of the union of datatypes.

The class of unions of datatypes is defined as follows:

The property which denotes a constituent datatype of a union of datatypes is defined as follows:

As a way of checking for data integrity during discovery, an additional property is provided representing the number of constituent datatypes of the union of datatype:

Standard datatypes

This standard recommends the use of the xsd:string, xsd:boolean, xsd:integer and xsd:anyURI datatypes defined in [XSD Pt2] to represent strings, booleans, integers and IRIs, respectively. They are described in the following subsections.

http://www.w3.org/2001/XMLSchema#integer

This section also contains a summary of the rdf:langString datatype which is used heavily by FHISO technologies.

The xsd:string datatype

Some FHISO standards make limited use of the xsd:string datatype defined in §3.3.1 of [XSD Pt2]. This is an unstructured non-language-tagged datatype which has the following properties:

It is a general-purpose datatype whose lexical space is the space of all strings; however it is not a language-tagged datatype and therefore it should not be used to contain text in a human-readable natural language.

Use of this datatype is generally not recommended: data that is in a human-readable form should use a language-tagged datatype, while data that is not human-readable should use a structured datatype.

If an application encounters a string with the xsd:string datatype in a context where a language-tagged string would be permitted, the application may change the datatype to rdf:langString and assign the string a language tag of und, meaning an undetermined language.

The xsd:boolean datatype

A boolean is a datatype with precisely two logical values: true and false. FHISO standards represent booleans using the xsd:boolean datatype defined in §3.3.2 of [XSD Pt2]. This is a structured non-language-tagged datatype which has the following properties:

The lexical space of this datatype includes four different strings so that the two logical values of the datatype each have two alternative lexical representations. The value true may be represented by either "true" or "1", while the value false may be represented by either "false" or "0". Conformant applications shall not attach any significance to which of the alternative lexical representations is used, and may replace any instance of "1" in a boolean string with "true", or "0" with "false", but not vice versa. Where possible, the numeric representations, "0" and "1", should not be used.

The xsd:integer datatype

FHISO uses the xsd:integer datatype defined in §3.4.13 of [XSD Pt2] to represent integers. It must not be used for values which are typically but not invariably integers.

This datatype can represent arbitrarily large integers, but unless otherwise stated, applications may opt not to support values greater than 2 147 483 647 or less than −2 147 483 648. In the event an unsupported value is encountered, an implementation may handle it in an implementation-defined manner, but must not convert it to a different integer.

The lexical space of this datatype is the space of all strings consisting of a finite-length sequence of one or more decimal digits (U+0030 to U+0039, inclusive), optionally preceded by a + or - sign (U+002B or U+002D, respectively).

This datatype has several alternative representations of the same logical integer value. This arises because leading zeros are permitted, the + sign is optional, and the value -0 is permitted. Applications may remove any leading + sign and any leading zeros preceding a non-zero digit, and may rewrite -0 as 0.

This is a structured non-language-tagged datatype which has the following properties:

The xsd:anyURI datatype

FHISO uses the xsd:anyURI datatype defined in §3.3.17 of [XSD Pt2] to represent strings which are valid IRIs.

Formally this is an unstructured datatype with no restrictions imposed on its lexical space; nevertheless, this datatype should only be used with strings which match the IRI-reference production in §2.2 of [RFC 3987] which matches both absolute and relative IRIs.

The rdf:langString datatype

The rdf:langString datatype defined in §2.5 of [RDFS] is used as the general-purpose unstructured language-tagged datatype. No constraints are placed on the lexical space of this datatype; the only restriction placed on the use or semantics of this datatype is that it should contain text in a human-readable form.

Any language-tagged datatype that is not defined to be a subtype of some other datatype shall implicitly be considered to be a subtype of the rdf:langString datatype.

This datatype has the following properties:

The xsd:anyAtomicType datatype

The xsd:anyAtomicType datatype defined in defined §3.2.2 of [XSD Pt2] is used as the universal supertype of all datatypes.

This datatype has the following properties:

Any non-language-tagged datatype not defined to be a subtype of any other datatype shall implicitly be considered to be a subtype of the xsd:anyAtomicType datatype.

References

Normative references

[ISO 10646]

ISO (International Organization for Standardization). ISO/IEC 10646:2014. Information technology — Universal Coded Character Set (UCS). 2014.

[FHISO Patterns]

FHISO (Family History Information Standards Organisation). The Pattern Datatype. First public draft.

[RDFS]

W3C (World Wide Web Consortium). RDF Schema 1.1. W3C Recommendation, 2014. (See https://www.w3.org/TR/rdf-schema.)

[RFC 2119]

IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Scott Bradner, eds., 1997. (See https://tools.ietf.org/html/rfc2119.)

[RFC 3987]

IETF (Internet Engineering Task Force). RFC 3987: Internationalized Resource Identifiers (IRIs). Martin Duerst and Michel Suignard, eds., 2005. (See https://tools.ietf.org/html/rfc3987.)

[RFC 5646]

IETF (Internet Engineering Task Force). RFC 5646: Tags for Identifying Languages. Addison Phillips and Mark Davis, eds., 2009. (See https://tools.ietf.org/html/rfc5646.)

[RFC 7230]

IETF (Internet Engineering Task Force). RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. Roy Fielding and Julian Reschke, eds., 2014. (See https://tools.ietf.org/html/rfc7230.)

[RFC 7231]

IETF (Internet Engineering Task Force). RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Roy Fielding and Julian Reschke, eds., 2014. (See https://tools.ietf.org/html/rfc7231.)

[Triples Discovery]

FHISO (Family History Information Standards Organisation). Simple Triples Discovery Mechanism. First public draft.

[UAX 15]

The Unicode Consortium. "Unicode Standard Annex 15: Unicode Normalization Forms" in The Unicode Standard, Version 8.0.0. Mark Davis and Ken Whistler, eds., 2015. (See http://unicode.org/reports/tr15/.)

[XML]

W3C (World Wide Web Consortium). Extensible Markup Language (XML) 1.1, 2nd edition. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, and John Cowan eds., 2006. W3C Recommendation. (See https://www.w3.org/TR/xml11/.)

Other references

[ANSEL]

NISO (National Information Standards Organization). ANSI/NISO Z39.47-1993. Extended Latin Alphabet Coded Character Set for Bibliographic Use. 1993. (See http://www.niso.org/apps/group_public/project/details.php?project_id=10.) Standard withdrawn, 2013.

[CEV Concepts]

FHISO (Family History Information Standards Organisation). *Citation Elements: General Concepts". Third public draft. See https://fhiso.org/TR/cev-concepts.

[CEV RDFa]

FHISO (Family History Information Standards Organisation). Citation Elements: Bindings for RDFa. Third public draft. (See https://fhiso.org/TR/cev-rdfa-bindings.)

[CEV Vocabulary]

FHISO (Family History Information Standards Organisation). Citation Elements: Vocabulary. Exploratory draft.

[GEDCOM]

The Church of Jesus Christ of Latter-day Saints. The GEDCOM Standard, draft release 5.5.1. 2 Oct 1999.

[IANA Lang Subtags]

IANA (Internet Assigned Numbers Authority). Language Subtag Registry. Online data file. (See http://www.iana.org/assignments/language-subtag-registry.)

[ISO 639-1]

ISO (International Organization for Standardization). ISO 639-1:2002. Codes for the representation of names of languages — Part 1: Alpha-2 code. 2002.

[ISO 639-2]

ISO (International Organization for Standardization). ISO 639-2:1998. Codes for the representation of names of languages — Part 2: Alpha-3 code. 1998. (See http://www.loc.gov/standards/iso639-2/.)

[ISO 639-3]

ISO (International Organization for Standardization). ISO 639-3:2007. Codes for the representation of names of languages — Part 3: Alpha-3 code for comprehensive coverage of languages. 2007.

[ISO 639-5]

ISO (International Organization for Standardization). ISO 639-5:2007. Codes for the representation of names of languages — Part 5: Alpha-3 code for language families and groups. 2008.

[ISO 3166-1]

ISO (International Organization for Standardization). ISO 3166-1:2006. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes. 2006. (See https://www.iso.org/iso-3166-country-codes.html.)

[ISO 15924]

ISO (International Organization for Standardization). ISO 15924:2004. Codes for the representation of names of scripts. 2004.

[N-Triples]

W3C (World Wide Web Consortium). RDF 1.1 N-Triples. David Becket, 2014. W3C Recommendation. (See https://www.w3.org/TR/n-triples/.)

[RDF Concepts]

W3C (World Wide Web Consortium). RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak, David Wood and Markus Lanthaler, eds., 2014. W3C Recommendation. (See https://www.w3.org/TR/rdf11-concepts/.)

[RDF Schema]

W3C (World Wide Web Consortium). RDF Schema 1.1. Dan Brickley and R. V. Guha, eds., 2014. W3C Recommendation. (See https://www.w3.org/TR/rdf-schema.)

[RFC 4122]

IETF (Internet Engineering Task Force). A Universally Unique IDentifier (UUID) URN Namespace. P. Leach, M. Mealling and R. Salz, ed., 2005. (See https://tools.ietf.org/html/rfc4122.)

[RFC 4648]

IETF (Internet Engineering Task Force). RFC 4648: The Base16, Base32, and Base64 Data Encodings. S. Josefsson, ed., 2006. (See https://tools.ietf.org/html/rfc4648.)

[RFC 7159]

IETF (Internet Engineering Task Force). RFC 7159: The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, ed., 2014. (See https://tools.ietf.org/html/rfc7159.)

[RFC 7469]

IETF (Internet Engineering Task Force). Public Key Pinning Extension for HTTP. C. Evans, C. Palmer and R. Sleevi, ed., 2015. (See https://tools.ietf.org/html/rfc7469.)

[SWBP XSD DT]

W3C (World Wide Web Consortium). XML Schema Datatypes in RDF and OWL. Jeremy J. Carroll and Jeff Z. Pan, eds., 2006. W3C Working Group Note.
(See https://www.w3.org/TR/swbp-xsch-datatypes/.)

[UN M.49]

United Nations, Statistics Division. Standard Country or Area Codes for Statistical Use, revision 4. United Nations publication, Sales No. 98.XVII.9, 1999.

[XML Names]

W3C (World Wide Web Consortium). Namespaces in XML 1.1, 2nd edition. Tim Bray, Dave Hollander, Andrew Layman and Richard Tobin, ed., 2006. W3C Recommendation. (See https://www.w3.org/TR/xml-names11/.)

[XSD Pt1]

W3C (World Wide Web Consortium). W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures. Shudi Gao (高殊镝), C. M. Sperberg-McQueen and Henry S. Thompson, ed., 2012.
W3C Recommendation. (See https://www.w3.org/TR/xmlschema11-1/.)

[XSD Pt2]

W3C (World Wide Web Consortium). W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson, Shudi Gao (高殊镝), Ashok Malhotra, C. M. Sperberg-McQueen and Henry S. Thompson, ed., 2012. W3C Recommendation. (See https://www.w3.org/TR/xmlschema11-2/.)

Copyright © 2017–18, Family History Information Standards Organisation, Inc. The text of this standard is available under the Creative Commons Attribution 4.0 International License.