diff --git a/Gemfile.lock b/Gemfile.lock index ab905ab6..fcfed99e 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -1,6 +1,6 @@ GIT remote: https://github.com/ruby-rdf/json-ld.git - revision: 172e0c960c9771fa9f963eca55d28fb63bce56b0 + revision: adbd407fa4b5783c8a7f7b79653b6e38815ff854 branch: develop specs: json-ld (3.0.2) @@ -14,8 +14,8 @@ GIT GEM remote: https://rubygems.org/ specs: - addressable (2.6.0) - public_suffix (>= 2.0.2, < 4.0) + addressable (2.7.0) + public_suffix (>= 2.0.2, < 5.0) bcp47 (0.3.3) i18n builder (3.2.3) @@ -28,7 +28,7 @@ GEM sxp (~> 1.0) equivalent-xml (0.6.0) nokogiri (>= 1.4.3) - haml (5.1.1) + haml (5.1.2) temple (>= 0.8.0) tilt hamster (3.0.0) @@ -37,7 +37,7 @@ GEM i18n (1.6.0) concurrent-ruby (~> 1.0) json-canonicalization (0.1.0) - json-ld-preloaded (3.0.3) + json-ld-preloaded (3.0.4) json-ld (~> 3.0) multi_json (~> 1.12) rdf (~> 3.0) @@ -77,11 +77,11 @@ GEM multi_json (1.13.1) net-http-persistent (3.1.0) connection_pool (~> 2.2) - nokogiri (1.10.3) + nokogiri (1.10.4) mini_portile2 (~> 2.4.0) nokogumbo (1.5.0) nokogiri - public_suffix (3.1.1) + public_suffix (4.0.1) rack (2.0.7) rake (12.3.3) rdf (3.0.12) @@ -135,7 +135,7 @@ GEM rdf-turtle (3.0.6) ebnf (~> 1.1) rdf (~> 3.0) - rdf-vocab (3.0.8) + rdf-vocab (3.0.10) rdf (~> 3.0, >= 3.0.11) rdf-xsd (3.0.1) rdf (~> 3.0) @@ -160,8 +160,8 @@ GEM rdf (~> 3.0) sxp (1.0.2) rdf (~> 3.0) - temple (0.8.1) - tilt (2.0.9) + temple (0.8.2) + tilt (2.0.10) PLATFORMS ruby diff --git a/common/common.js b/common/common.js index 8377a96c..dd3c14d6 100644 --- a/common/common.js +++ b/common/common.js @@ -33,14 +33,23 @@ function restrictReferences(utils, content) { return (base.innerHTML); } -// add a handler to come in after all the definitions are resolved -// -// New logic: If the reference is within a 'dl' element of -// class 'termlist', and if the target of that reference is -// also within a 'dl' element of class 'termlist', then -// consider it an internal reference and ignore it. require(["core/pubsubhub"], (respecEvents) => { "use strict"; + +// remote data-cite on where the citation is to ourselves. + respecEvents.sub('end', (message) => { + const selfDfns = document.querySelectorAll("dfn[data-cite^='" + respecConfig.shortName.toUpperCase() + "']"); + for (const dfn of selfDfns) { + delete dfn.dataset.cite; + } + }); + + // add a handler to come in after all the definitions are resolved + // + // New logic: If the reference is within a 'dl' element of + // class 'termlist', and if the target of that reference is + // also within a 'dl' element of class 'termlist', then + // consider it an internal reference and ignore it. respecEvents.sub('end', (message) => { if (message === 'core/link-to-dfn') { // all definitions are linked; find any internal references diff --git a/common/terms.html b/common/terms.html index b2d15ea6..33c0768e 100644 --- a/common/terms.html +++ b/common/terms.html @@ -169,7 +169,8 @@ A set of rules for interpreting a JSON-LD document as specified in the The Context section of JSON-LD 1.1.
default language
- The default language is set in the context using the @language key + The default language is the language used when a string does not have a language associated with it directly. + It can be set in the context using the @language key whose value MUST be a string representing a [[BCP47]] language code or null.
default object
A default object is a map that has a @default key.
@@ -223,14 +224,14 @@ and its keys are interpreted as IRIs representing the @id of the associated node object. If a value in the id map contains a key expanding to @id, - it's value MUST be equivalent to the referencing key in the id map. + its value MUST be equivalent to the referencing key in the id map.
implicitly named graph
A named graph created from the value of a map entry having an expanded term definition where @container is set to @graph.
included block
An included block is an entry in a node object where the key is either `@included` or an alias of `@included` - and the value is one ore more node objects.
+ and the value is one or more node objects.
index map
An index map is a map value of a term defined with @container set to @index, @@ -344,7 +345,7 @@ representing the @type of the associated node object; the value MUST be a node object, or array of node objects. If the value contains a term expanding to @type, - it's values are merged with the map value when expanding.
+ its values are merged with the map value when expanding.
typed value
A typed value consists of a value, which is a string, diff --git a/index.html b/index.html index ef6e930d..b5d0dacb 100644 --- a/index.html +++ b/index.html @@ -267,7 +267,7 @@

JSON is a useful data serialization and messaging format. - This specification defines JSON-LD, a JSON-based format to serialize + This specification defines JSON-LD 1.1, a JSON-based format to serialize Linked Data. The syntax is designed to easily integrate into deployed systems that already use JSON, and provides a smooth upgrade path from JSON to JSON-LD. @@ -329,8 +329,9 @@

Introduction

JSON-LD is designed to be usable directly as JSON, with no knowledge of RDF - [[RDF11-CONCEPTS]]. It is also designed to be usable as RDF, if desired, for - use with other Linked Data technologies like SPARQL [[SPARQL11-OVERVIEW]]. Developers who + [[RDF11-CONCEPTS]]. It is also designed to be usable as RDF + in conjunction with other Linked Data technologies like SPARQL [[SPARQL11-OVERVIEW]]. + Developers who require any of the facilities listed above or need to serialize an RDF graph or Dataset in a JSON-based syntax will find JSON-LD of interest. People intending to use JSON-LD with RDF tools will find it can be used as another @@ -426,9 +427,9 @@

Design Goals and Rationale

Simplicity
No extra processors or software libraries are necessary to use JSON-LD in its most basic form. The language provides developers with a very easy - learning curve. Developers only need to know JSON and two - keywords (@context - and @id) to use the basic functionality in JSON-LD.
+ learning curve. Developers not concerned with Linked Data only need to understand JSON, + and know to include but ignore the @context property, + to use the basic functionality in JSON-LD.
Compatibility
A JSON-LD document is always a valid JSON document. This ensures that all of the standard JSON libraries work seamlessly with JSON-LD documents.
@@ -466,21 +467,20 @@

Design Goals and Rationale

Data Model Overview

-

Generally speaking, the data model described by a - JSON-LD document is a labeled, - directed graph. The graph contains - nodes, which are connected by - directed-arcs. A node is typically data - such as a string, number, - typed values (like dates and times) - or an IRI.

-

Within a directed graph, nodes may - be unnamed, i.e., not identified by an IRI or representing - data such as strings or numbers. Such nodes are called blank nodes, +

Generally speaking, the data model described by a JSON-LD document is a labeled, directed graph. + The graph contains nodes, which are connected by directed-arcs. + A node is either a resource with properties, or the data values of those properties including + strings, numbers, typed values (like dates and times) and IRIs.

+

Within a directed graph, nodes are resources, and may + be unnamed, i.e., not identified by an IRI; + which are called blank nodes, and may be identified using a blank node identifier. These identifiers may be required to represent a fully connected graph using a tree structure, such as JSON, but otherwise have no - intrinsic meaning.

+ intrinsic meaning. + Literal values, such as strings and numbers, are also considered resources, + and JSON-LD distinguishes between node objects and value objects to distinguish between the different + kinds of resource.

This simple data model is incredibly flexible and powerful, capable of modeling almost any kind of data. For a deeper explanation of the data model, see @@ -584,11 +584,10 @@

Syntax Tokens and Keywords

IRI. This keyword is described in .
@graph
Used to express a graph. This keyword is described in .
-
@nest
Collects a set of nested properties within - a node object.
+
@nest
Used to define a property of a node object that groups together properties of that node, but is not an edge in the graph.
@none
Used as an index value in an index map, id map, language map, type map, or elsewhere where a map is - used to index into other values.
+ used to index into other values, when the indexed node does not have the feature being indexed.
@prefix
With the value true, allows this term to be used to construct a compact IRI when compacting.
@@ -597,6 +596,9 @@

Syntax Tokens and Keywords

New features since [[[JSON-LD10]]] [[JSON-LD10]] described in this specification are only available when processing mode has been explicitly set to json-ld-1.1. +
Within a context definition `@version` takes the specific value `1.1`, not + `"json-ld-1.1"`, as a JSON-LD 1.0 processor may accept a string value for `@version`, + but will reject a numeric value.
@json
Used as the @type value of a JSON literal. @@ -605,7 +607,7 @@

Syntax Tokens and Keywords

:
The separator for JSON keys and values that use compact IRIs.
`@propagate`
- Used in a context definition to change the sccope of that context. + Used in a context definition to change the scope of that context. By default, it is `true`, meaning that contexts propagate across node objects (other than for type-scoped contexts, which default to `false`). @@ -805,10 +807,13 @@

The Context

terms to communicate with one another more efficiently, but without losing accuracy.

-

Simply speaking, a context is used to map terms to - IRIs. Terms are case sensitive - and any valid string that is not a reserved JSON-LD keyword - can be used as a term.

+

Simply speaking, a context is used to map terms to IRIs. + Terms are case sensitive and most any valid string that is not a reserved JSON-LD keyword + can be used as a term. + The empty string `""` and strings that have the form + of a keyword (e.g., staring with `"@"`) must not be used as terms. + Strings that have the form of + an absolute IRI (e.g., containing a `":"`) should not be used as terms.

For the sample document in the previous section, a context would look something like this:

@@ -948,7 +953,9 @@

The Context

contexts may also be specified inline. This has the advantage that documents can be processed even in the absence of a connection to the Web. Ultimately, this is a modeling decision - and different use cases may require different handling.

+ and different use cases may require different handling. + See See Security Considerations in + for a discussion other considerations for using remote contexts.

-
List Objects and Set objects
+
List Objects and Set objects
+ List Objects are a special kind of JSON-LD maps, + distinct from node objects and value objects, + used to express ordered values by wrapping an array in a map under the key `@list`. + Set Objects exist for uniformity, and are equivalent to the array value of the `@set` key. + See and + for more detail. +
Map Objects
JSON-LD uses various forms of maps as ways to more easily access values of a property.
@@ -1641,7 +1655,7 @@

Advanced Concepts

further discussion.

Property nesting

Another JSON idiom often found in APIs is to use an - intermediate object to represent the properties of an object; in JSON-LD + intermediate object to to group together related properties of an object; in JSON-LD these are referred to as nested properties and are described in .

Referencing objects
@@ -2126,6 +2140,16 @@

Advanced Concepts

The following example specifies an external context and then layers an embedded context on top of the external context:

+

In JSON-LD 1.1, there are other mechanisms for introducing contexts, including + scoped contexts and imported contexts, and there are new ways of protecting term definitions, + so there are cases where the last defined inline context is not necessarily one + which defines the scope of terms. + See , + , + , and + + for further information.

+

Base IRI

@@ -2597,6 +2554,76 @@

Using the Document Base for the Default Vocabulary

external contexts.

+
+

Using the Document Base for the Default Vocabulary

+

In some cases, vocabulary terms are defined directly within the document + itself, rather than in an external vocabulary. + Since json-ld-1.1, the vocabulary mapping in a local context + can be set to a relative IRI, + which is, if there is no vocabulary mapping in scope, resolved against the base IRI. + This causes terms which are expanded relative to the vocabulary, + such as the keys of node objects, + to be based on the base IRI to create absolute IRIs.

+ +
+
+
+ +

If this document were located at http://example/document, it would expand as follows:

+ + +
+

Compact IRIs

A compact IRI is a way of expressing an IRI @@ -2946,7 +2973,7 @@

Using the Document Base for the Default Vocabulary

In this case, the property term would not normally be usable as a prefix, both because it is defined with an expanded term definition, and because - it's @id does not end in a + its @id does not end in a gen-delim character. Adding "@prefix": true allows it to be used as the prefix portion of the compact IRI property:One.

@@ -3214,8 +3241,8 @@

Using the Document Base for the Default Vocabulary

property, which defines a context (a scoped context) for values of properties defined using that term. When used for a property, this is called a property-scoped context. - This allows values to use term definitions, base IRI, - vocabulary mapping or default language which is different from the + This allows values to use term definitions, the base IRI, + vocabulary mappings or the default language which are different from the node object they are contained in, as if the context was specified within the value itself.

@@ -3413,96 +3440,97 @@

Using the Document Base for the Default Vocabulary

types are listed, the order that type-scoped contexts are applied is based on lexicographical ordering.

-

For example, consider the following semantically equivalent examples:

+

For example, consider the following semantically equivalent examples. + The first example, shows how properties and types can define their own + scoped contexts, which are included when expanding.

- + } + --> + + +

Contexts are processed depending on how they are defined. + A property-scoped context is processed first, + followed by any embedded context, + followed lastly by the type-scoped contexts, + in the appropriate order. The previous example is logically equivalent to the following:

+ +
+  
+  

If a term defines a scoped context, - and then that term is later re-defined, + and then that term is later redefined, the association of the context defined in the earlier expanded term definition is lost - within the scope of that re-definition. This is consistent with + within the scope of that redefnition. This is consistent with term definitions of a term overriding previous term definitions from earlier less deeply nested definitions, as discussed in .

@@ -3516,7 +3544,7 @@

Using the Document Base for the Default Vocabulary

context removes it by setting `@context` to `null`, or by redefining terms, with the exception of type-scoped contexts, - which limits the effect of that context until the next node object is entered. + which limit the effect of that context until the next node object is entered. This behavior can be changed using the `@propagate` keyword.

The following example illustrates how terms defined in a context with `@propagate` set to `false` @@ -3634,8 +3662,8 @@

Using the Document Base for the Default Vocabulary

additional type coercion information.

The following examples illustrate how `@import` can be used to express - a for type-scoped context that loads an imported context and - sets `@propagate` to `true` and how to make similar modifications.

+ a type-scoped context that loads an imported context and + sets `@propagate` to `true`, as a technique for making other similar modifications.

Suppose there was a context that could be referenced remotely via the URL https://json-ld.org/contexts/remote-context.jsonld:

@@ -3703,7 +3731,7 @@

Using the Document Base for the Default Vocabulary

Similarly, the wrapping context may replace term definitions or - set other context-wide keywords that may effect how the imported + set other context-wide keywords that may affect how the imported context term definitions will be processed:

Using the Document Base for the Default Vocabulary
   express the value of a type.

The @type keyword is also used to associate a type - with a node. The concept of a node type and - a value type are different. + with a node. + The concept of a node type and a value type are distinct. For more on adding types to nodes, see .

+

When expanding, an `@type` defined within a term definition + can be associated with a string value to create an expanded value object, + which is described in . + Type coercion only takes place on string values, not for values which are maps, + such as node objects and value objects in their expanded form.

+

A node type specifies the type of thing that is being described, like a person, place, event, or web page. A value type specifies the data type of a particular value, such @@ -4660,9 +4694,10 @@

Using the Document Base for the Default Vocabulary

"@context": { "@base": "http://example1.com/", "@vocab": "http://example2.com/", - "fred": {"@type": "@vocab"} + "knows": {"@type": "@vocab"} }, - "fred": [ + "@id": "fred", + "knows": [ {"@id": "barney", "mnemonic": "the sidekick"}, "barney" ] @@ -4674,15 +4709,13 @@

Using the Document Base for the Default Vocabulary

data-result-for="Term expansion for values, not identifiers-compacted">
@@ -4692,8 +4725,8 @@

Using the Document Base for the Default Vocabulary

SubjectPropertyValue http://example1.com/barneyhttp://example2.com/mnemonicthe sidekick - _:b0http://example2.com/fredhttp://example1.com/barney - _:b0http://example2.com/fredhttp://example2.com/barney + http://example1.com/fredhttp://example2.com/knowshttp://example1.com/barney + http://example1.com/fredhttp://example2.com/knowshttp://example2.com/barney
Using the Document Base for the Default Vocabulary
 
   ex1:barney ex2:mnemonic "the sidekick" .
 
-  [ ex2:fred ex2:barney, ex1:barney] .
+  ex1:fred ex2:knows ex1:barney, ex2:barney .
   -->
   
@@ -4731,7 +4764,7 @@

Using the Document Base for the Default Vocabulary

of @vocab illustrates the behavior of interpreting "barney" relative to the document:

- @@ -4797,7 +4829,7 @@

Using the Document Base for the Default Vocabulary

to be applied to keys which are not represented as a simple term. For example:

-

String Internationalization

@@ -4965,7 +4993,7 @@

Using the Document Base for the Default Vocabulary

string values that are not type coerced.

To clear the default language for a subtree, @language can - be set to null in a local context as follows:

+ be set to null in an intervening context, such as a scoped context as follows:

@@ -4973,15 +5001,17 @@ 

Using the Document Base for the Default Vocabulary

{ "@context": { ####...#### - "@language": "ja" + ****"@version": 1.1,**** + "@vocab": "http://example.com/", + "@language": "ja", + "details": { + ****"@context": { + "@language": null + }**** + } }, "name": "花澄", - "details": { - ****"@context": { - "@language": null - }****, - "occupation": "Ninja" - } + "details": {"occupation": "Ninja"} } -->
@@ -5052,7 +5082,10 @@

Using the Document Base for the Default Vocabulary

example but consolidates all values in a single property. To access the value in a specific language in a programming language supporting dot-notation accessors for object properties, a developer may use the - property.language pattern. For example, to access the occupation + property.language pattern + (when languages are limited to the primary language sub-tag, + and do not depend on other sub-tags, such as `"en-us"`). + For example, to access the occupation in English, a developer would use the following code snippet: obj.occupation.en.

@@ -6469,9 +6502,7 @@

Using the Document Base for the Default Vocabulary

A node object, like the one used above, may be used in - any value position in the body of a JSON-LD document. Note that type coercion of the knows property - is not required, as the value is not a string.

+ any value position in the body of a JSON-LD document.

While it is considered a best practice to identify nodes in a graph, at times this is impractical. In the data model, nodes without an explicit @@ -7398,7 +7429,9 @@

Using the Document Base for the Default Vocabulary

de keys are implicitly associated with their respective values by the JSON-LD Processor. This allows a developer to access the German version of the label using the - following code snippet: obj.label.de.

+ following code snippet: obj.label.de, + which, again, is only appropriate when languages are limited to the + primary language sub-tag and do not depend on other sub-tags, such as `"en-us"`.

The value of @container can also be an array containing both @language and @set. @@ -11641,8 +11674,7 @@

Terms

A term is a short-hand string that expands to an IRI or a blank node identifier.

-

A term MUST NOT equal any of the JSON-LD - keywords.

+

A term MUST NOT equal any of the JSON-LD keywords.

When used as the prefix in a Compact IRI, to avoid the potential ambiguity of a prefix being confused with an IRI @@ -12055,7 +12087,7 @@

Id Maps

or a term which expands to @none, and the values MUST be node objects.

-

If the value contains a property expanding to @id, it's value MUST +

If the value contains a property expanding to @id, its value MUST be equivalent to the referencing key. Otherwise, the property from the value is used as the @id of the node object value when expanding.

@@ -12081,7 +12113,7 @@

Type Maps

and the values MUST be node objects or strings which expand to node objects.

-

If the value contains a property expanding to @type, and it's value +

If the value contains a property expanding to @type, and its value is contains the referencing key after suitable expansion of both the referencing key and the value, then the node object already contains the type. Otherwise, the property from the value is added as a @type of the node object value when expanding.