Original
Expanded
@@ -1874,7 +2002,7 @@
Advanced Concepts
-->
+ data-result-for="Embedded contexts within node objects-original">
Subject Property Value
@@ -1898,7 +2026,7 @@ Advanced Concepts
-
+
expanded term definitions where the term is a
keyword are ignored.
+ When processing mode is set to
json-ld-1.1, there is an exception for
@type;
+ see
for further details.
Since keywords cannot be redefined, they can also not be aliased to
other keywords.
@@ -2910,7 +3018,7 @@
Using the Document Base for the Default Vocabulary
Scoped Contexts
An expanded term definition can include a @context
- property, which defines a context (an embedded context ) for
+ property, which defines a context (a scoped context ) for
values of properties defined using that term . This allows
values to use term definitions , base IRI ,
vocabulary mapping or default language which is different from the
@@ -2993,7 +3101,7 @@
Using the Document Base for the Default Vocabulary
In this case, the social profile is defined using the schema.org vocabulary, but interest is imported from FOAF, and is used to define a node describing one of Manu's interests where those properties now come from the FOAF vocabulary.
- Expanding this document, uses a combination of terms defined in the outer context, and those defined specifically for that term in an embedded context .
+ Expanding this document, uses a combination of terms defined in the outer context, and those defined specifically for that term in a scoped context .
Scoping can also be performed using a term used as a value of @type:
@@ -3089,26 +3197,109 @@ Using the Document Base for the Default Vocabulary
different things depending on the context.
When expanding, each value of @type is considered
- (ordering them lexographically) where that value is also a term in
- the active context having its own embedded context . If so, that
- embedded context is applied to the active context . When compacting, if
- a term is chosen to represent an IRI used as a value of @type where that
- term definition also has an embedded context , it is then applied to the
- active context to affect further compaction.
+ (ordering them lexicographically) where that value is also a term in
+ the active context having its own scoped context . If so, that
+ scoped context is applied to the active context .
The values of @type are unordered, so if multiple
- types are listed, the order that scoped contexts are applied is based on
+ types are listed, the order that scoped contexts are applied is based on
lexicographical ordering.
- If a term defines a scoped context, and then that term
- is later re-defined, the association of the context defined in the earlier
+
For example, consider the following semantically equivalent examples:
+
+
+ This example, shows how properties and types can define their own
+ scoped contexts, which are included when expanding.
+
+
+
+
+ Contexts are processed depending on how their defined. A scoped context
+ for a property is processed first, followed by the scoped contexts for any
+ types, in the appropriate order, followed lastly by any embedded context.
+ The previous example is logically equivalent to the following:
+
+
+
+
+
+ If a term defines a scoped context ,
+ and then that term is later re-defined,
+ 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
term definitions of a term overriding previous term definitions from
earlier less deeply nested definitions, as discussed in
- Scoped Contexts are a new feature in JSON-LD 1.1, requiring
+
Scoped Contexts are a new feature in JSON-LD 1.1, requiring
processing mode set to json-ld-1.1.
@@ -3672,6 +3863,11 @@
Using the Document Base for the Default Vocabulary
compact IRI or
absolute IRI if a colon is present; otherwise, they are interpreted
as
relative IRI .
+
The ability to coerce a value using a term definition is distinct
+ from setting one or more types on a node object , as the former does not result in
+ new data being added to the graph, while the later manages node types
+ through adding additional relationships to the graph.
+
Terms or compact IRIs used as the value of a
@type key may be defined within the same context. This means that one may specify a
term like xsd and then use xsd:integer within the same
@@ -3862,12 +4058,17 @@
Using the Document Base for the Default Vocabulary
The unexpected result is that "barney" expands to both http://example1.com/barney
and http://example2.com/barney, depending where it is encountered.
- String values interpreted as IRIs because of the associated term definition
+ String values interpreted as IRIs because of the associated term definitions
are typically considered to be document-relative.
In some cases, it makes sense to interpret these relative to the vocabulary,
prescribed using "@type": "@vocab" in the term definition , though this can
- lead to unexpected consequences such as these.
- For more on this see
+ lead to unexpected consequences such as these.
+
+
In the previous example, "barney" appears twice, once as the value of @id,
+ which is always interpreted as a document-relative IRI, and once as the value of
+ "fred", which is defined to be vocabulary-relative, thus the different exapanded values.
+
+
For more on this see
A variation on the previous example using "@type": "@id" instead
of @vocab illustrates the behavior of interpreting "barney" relative to the document:
@@ -4681,12 +4882,14 @@
Using the Document Base for the Default Vocabulary
rdf:nil. This can be represented as statments, as the "statements"
tab illustrates.
-
Both JSON-LD and Turtle provide shortcuts for representing ordered lists.
In JSON-LD 1.1, lists of lists, where the value of
a list object , may itself be a list object , are
- fully supported. For example, in GeoJSON (see [[RFC7946]]),
+ fully supported.
+
+
Note that the "@container": "@list" definintion recursively
+ describes array values of lists as being, themselves, lists. For example, in GeoJSON (see [[RFC7946]]),
coordinates are an ordered list of positions , which are
represented as an array of two or more numbers:
@@ -5048,6 +5251,27 @@
Using the Document Base for the Default Vocabulary
represented using arrays. See
for a further discussion.
+
+
@@ -5242,9 +5466,12 @@
Using the Document Base for the Default Vocabulary
-
Similarly, node objects may contain a @nest property to
- reference a term aliased to @nest which causes such
- values to be nested under that aliased term.
+
Similarly, term definitions may contain a @nest property
+ referencing a term aliased to @nest which will cause such
+ properties to be nested under that aliased term when compacting.
+ In the example below, both main_label and other_label are defined
+ with "@nest": "labels", which will cause them to be serialized under
+ labels when compacting.
@@ -5268,10 +5495,10 @@ Using the Document Base for the Default Vocabulary
},
"@id": "http://example.org/myresource",
"homepage": "http://example.org",
- "labels": {
+ ****"labels": {
"main_label": "This is the main label for my resource",
"other_label": "This is the other label"
- }
+ }****
}
-->
@@ -5997,7 +6224,7 @@ Using the Document Base for the Default Vocabulary
In the example above, the post term has
been marked as an index map . The en and
de keys will be ignored semantically, but preserved
- syntactically, by the JSON-LD Processor . This allows a developer to
+ syntactically, by the JSON-LD Processor . If used in JavaScript, this can allow a developer to
access the German version of the post using the
following code snippet: obj.post.de.
@@ -6290,7 +6517,7 @@ Using the Document Base for the Default Vocabulary
In the example above, the label term has
- been marked as an language map . The en and
+ been marked as a language map . The en and
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
@@ -6912,7 +7139,7 @@
Using the Document Base for the Default Vocabulary
In the example above, the affiliation term has
- been marked as an type map . The schema:Corporation and
+ been marked as a type map . The schema:Corporation and
schema:ProfessionalService keys will be interpreted
as the @type property of the node object value.
@@ -8875,7 +9102,7 @@
Graph Containers
In order to use an external context with an ordinary JSON document,
when retrieving an ordinary JSON document via HTTP, processors MUST
- retrieve any JSON-LD document referenced by a
+ attempt to retrieve any JSON-LD document referenced by a
Link Header with:
@@ -9764,7 +9985,7 @@
Node Objects
Graph Objects
A graph object represents a named graph , which MAY include
- include an explicit graph name .
+ an explicit graph name .
A dictionary is a graph object if
it exists outside of a JSON-LD context ,
it is not a node object ,
@@ -9853,11 +10074,11 @@
Lists and Sets
A list object MUST be a dictionary that contains no
keys that expand to an absolute IRI or keyword other
- than @list, @context, and @index.
+ than
@list and
@index.
A set object MUST be a dictionary that contains no
keys that expand to an absolute IRI or keyword other
- than @set, @context, and @index.
+ than @set and @index.
Please note that the @index key will be ignored when being processed.
In both cases, the value associated with the keys @list and @set
@@ -9935,8 +10156,9 @@
Index Maps
set to an array containing both
@graph and
@index, and optionally including
@set. The
value consists of the
node objects contained within the
named
- graph which is named using the referencing key, which can be
- represented as a
simple graph object .
+ graph which is indexed using the referencing key, which can be
+ represented as a
simple graph object if the value does
+ not include
@id, or a
named graph if it includes
@id.
@@ -10984,31 +11206,13 @@ Security Considerations
Open Issues
The following is a list of issues open at the time of publication.
Consider using "@type": "@json" to describe native values in the compact form.
- When requesting JSON-LD from an HTTP endpoint, it would be useful to provide a reference to a context or frame which should be used by the server to put the results into the proper format.
Provide a means for refering to a remote context without without requiring it to be downloaded.
Consider a mechanism such as Microdata's @itemref for including objects within another referencing node.
Mechinism to allow freezing terms so that additional contexts don't override them.
- Should consider html>head>base@href and xml:base, as appropriate.
- Update terminology in the spec from IRI to URL .
- Proposal is to start from scratch, ie, deprecating @graph and replacing the functionality with something cleaner.
-
-
-Give each JSON-LD feature a name. For example: aliasing, reverseProperties, typeCoercion, etc.
-Each JSON-LD version will officially support a set of these features. For example, JSON-LD 1.0 supports roughly ~20, JSON-LD 1.1 supports roughly ~30, and so on.
-Move some of these less-used features (based on real world data/usage) into a "Advanced JSON-LD Features" specification to keep the base specification simpler and more easily readable.
-Extend the @version keyword to take an array, where you can specify experimental extensions. For example: "@version": [1.1, "amazingExtensionFoo", "nicheExtensionBar"] - processors throw if they don't understand every extension listed.
-
-
Consider documentation best practices.
- Consider issues surrounding confusion of differing expansion rules for @id, @type, and dictionary members .
Define a recommended context to import.
-
-
Node Types in @context.
-
-
-