-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Short, labeled EXID-TYPE #307
base: sandbox
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -317,6 +317,27 @@ where: | |
|
||
The URI for the `MediaType` data type is `dcat:mediaType`. | ||
|
||
## Shortened URI | ||
|
||
A URI, possibly shorted and documented using a [documented extension tag](#extension-tags). | ||
|
||
```abnf | ||
ShortURI = extTag / URI | ||
``` | ||
|
||
where: | ||
|
||
* `URI` is defined in [STD 66](https://www.rfc-editor.org/info/std66) section 3 | ||
as what is commonly called an "absolute URI"; notably, it always includes a colon. | ||
|
||
* Any `extTag` used shall be documented in the [schema] as a [documented extension tag](#extension-tags). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. make There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With the pandoc, the tool used to render this markdown, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. github doesn't render |
||
As with other documented extension tags, the tag may be changed without changing the meaning of the data | ||
provided that the URI it represents does not change. | ||
|
||
Using `extTag` is preferred when the same URI would occur repeatedly in the dataset | ||
or when substructures of `g7:TAG` are used in the documented extension tag definition to provide additional information. | ||
|
||
|
||
## Special | ||
|
||
The special data type is a string conforming to a case-specific standard or constraints. The constraints on each special data type instance are either unique to that structure type or are not simply expressed. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -134,6 +134,8 @@ n HEAD {1:1} g7:HEAD | |
+2 VERS <Special> {1:1} g7:GEDC-VERS | ||
+1 SCHMA {0:1} g7:SCHMA | ||
+2 TAG <Special> {0:M} g7:TAG | ||
+3 LABEL <Text> {0:M} g7:LABEL | ||
+4 LANG <Language> {0:1} g7:LANG | ||
Comment on lines
+137
to
+138
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shouldn't this label be in the YAML file (where it already exists)? |
||
+1 SOUR <Special> {0:1} g7:HEAD-SOUR | ||
+2 VERS <Special> {0:1} g7:VERS | ||
+2 NAME <Text> {0:1} g7:NAME | ||
|
@@ -234,7 +236,7 @@ n @XREF:INDI@ INDI {1:1} g7:record-INDI | |
+1 <<PERSONAL_NAME_STRUCTURE>> {0:M} | ||
+1 SEX <Enum> {0:1} g7:SEX | ||
+2 EXID <Special> {0:M} g7:EXID | ||
+3 TYPE <Special> {0:1} g7:EXID-TYPE | ||
+3 TYPE <ShortURI> {0:1} g7:EXID-TYPE | ||
+1 <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> {0:M} | ||
+1 <<INDIVIDUAL_EVENT_STRUCTURE>> {0:M} | ||
+1 <<NEGATIVE_ASSERTION>> {0:M} | ||
|
@@ -247,7 +249,7 @@ n @XREF:INDI@ INDI {1:1} g7:record-INDI | |
+3 PHRASE <Text> {0:1} g7:PHRASE | ||
+2 <<NOTE_STRUCTURE>> {0:M} | ||
+2 EXID <Special> {0:M} g7:EXID | ||
+3 TYPE <Special> {0:1} g7:EXID-TYPE | ||
+3 TYPE <ShortURI> {0:1} g7:EXID-TYPE | ||
+1 FAMS @<XREF:FAM>@ {0:M} g7:FAMS | ||
+2 <<NOTE_STRUCTURE>> {0:M} | ||
+1 SUBM @<XREF:SUBM>@ {0:M} g7:SUBM | ||
|
@@ -592,7 +594,7 @@ n <<SOURCE_CITATION>> {0:M} | |
n <<MULTIMEDIA_LINK>> {0:M} | ||
n UID <Special> {0:M} g7:UID | ||
n EXID <Special> {0:M} g7:EXID | ||
+1 TYPE <Special> {0:1} g7:EXID-TYPE | ||
+1 TYPE <ShortURI> {0:1} g7:EXID-TYPE | ||
``` | ||
|
||
Substructures that may be shared by most individual and family events and attributes. | ||
|
@@ -716,7 +718,7 @@ n REFN <Special> {1:1} g7:REFN | |
n UID <Special> {1:1} g7:UID | ||
| | ||
n EXID <Special> {1:1} g7:EXID | ||
+1 TYPE <Special> {0:1} g7:EXID-TYPE | ||
+1 TYPE <ShortURI> {0:1} g7:EXID-TYPE | ||
] | ||
``` | ||
|
||
|
@@ -1105,7 +1107,7 @@ n NAME <PersonalName> {1:1} g7:INDI-NAME | |
+1 <<NOTE_STRUCTURE>> {0:M} | ||
+1 <<SOURCE_CITATION>> {0:M} | ||
+1 EXID <Special> {0:M} g7:EXID | ||
+2 TYPE <Special> {0:1} g7:EXID-TYPE | ||
+2 TYPE <ShortURI> {0:1} g7:EXID-TYPE | ||
``` | ||
|
||
Names of individuals are represented in the manner the name is normally spoken, with the family name, surname, or nearest cultural parallel thereunto separated by slashes (U+002F `/`). Based on the dynamic nature or unknown compositions of naming conventions, it is difficult to provide a more detailed name piece structure to handle every case. The `PERSONAL_NAME_PIECES` are provided optionally for systems that cannot operate effectively with less structured information. The Personal Name payload shall be seen as the primary name representation, with name pieces as optional auxiliary information; in particular it is recommended that all name parts in `PERSONAL_NAME_PIECES` appear within the `PersonalName` payload in some form, possibly adjusted for gender-specific suffixes or the like. | ||
|
@@ -1134,7 +1136,7 @@ n PLAC <List:Text> {1:1} g7:PLAC | |
+2 LATI <Special> {1:1} g7:LATI | ||
+2 LONG <Special> {1:1} g7:LONG | ||
+1 EXID <Special> {0:M} g7:EXID | ||
+2 TYPE <Special> {0:1} g7:EXID-TYPE | ||
+2 TYPE <ShortURI> {0:1} g7:EXID-TYPE | ||
+1 <<NOTE_STRUCTURE>> {0:M} | ||
``` | ||
|
||
|
@@ -1195,7 +1197,7 @@ n SOUR @<XREF:SOUR>@ {1:1} g7:SOUR | |
+1 <<MULTIMEDIA_LINK>> {0:M} | ||
+1 <<NOTE_STRUCTURE>> {0:M} | ||
+1 EXID <Special> {0:M} g7:EXID | ||
+2 TYPE <Special> {0:1} g7:EXID-TYPE | ||
+2 TYPE <ShortURI> {0:1} g7:EXID-TYPE | ||
``` | ||
|
||
A citation indicating that the pointed-to source record supports the claims made in the superstructure. | ||
|
@@ -1998,6 +2000,12 @@ A [Latter-Day Saint Ordinance](#latter-day-saint-ordinances). | |
See also `LDS_INDIVIDUAL_ORDINANCE`. Previously, GEDCOM versions 3.0 through 5.3 called this `WAC`; it was not part of 5.4 through 5.5.1. | ||
FamilySearch GEDCOM 7.0 reintroduced it with the name `INIL` for consistency with `BAPL`, `CONL`, and `ENDL`. | ||
|
||
#### `LABEL` (Label) `g7:LABEL` | ||
|
||
A recommended short label to use in displaying information described by the superstructure to the user. | ||
Multiple labels may be provided for the same superstructure. | ||
As with other structures, those with the same qualifying substructures (such as `g7:LANG`) are in user preference order. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does it mean to have a non-preferred label? |
||
|
||
#### `LANG` (Language) `g7:LANG` | ||
|
||
The primary human language of the superstructure. | ||
|
@@ -2842,7 +2850,7 @@ However, this is not required and a different URI for the set of issued identifi | |
|
||
Registered URIs are listed in [exid-types.json](https://github.com/FamilySearch/GEDCOM/blob/main/exid-types.json), where fields include: | ||
|
||
* "label": a short string suitable for display in a user interface. | ||
* "label": a short string suitable for display in a user interface. See also `g7:LABEL`, which may provide user-preferred alternative labels in the context of a particular dataset. | ||
* "type": The URI representing the authority issuing the `EXID`. | ||
* "description": A description of the meaning of the `EXID`. | ||
* "contact": A contact email address for the person or organization registering the URI. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not shure whether this solution leads to a way without extension tags in next minor/major. As the implementation in applications is not easy (so far they can build the complete link to the EXID directly), I would prefer a solution which remains very similar in following versions of the standard. Is there any idea how a solution without extension tags could work?
The proposed solution would work, but as the size of files is not very limiting, I see too much work for implementation compared to the temporary result.