The chosen default serialization for UCO content is json-ld. json-ld spec
json-ld is an officially supported serialization within the RDF ecosystem and is losslessly transformable by rdf tools to other rdf serializations.
The default fully expanded form of json-ld is referred to as "expanded" and contains full IRIs for all class types and properties.
Throughout this CP the "Device" example within the CASE examples repo will be utilized for illustrative purposes.
CASE Device example.
In expanded json-ld form this example would look like this:
JSON-LD provides a mechanism called a "context" that allows specification of particular details that allow a related body of json-ld content to be compacted to a more concise form. It also supports any amount of lossless compaction and expansion.
The Device example as it exists in the CASE examples repo currently applies a simple json-ld context to avoid having to repeatedly express IRI path detail for every object in the content.
Using this simple level of compaction yields the example in this form:
compaction of type assertions for properties such that the properties may be used on the body of content with just their value and not duplicative types assertions on each use
specification that particular properties should be represented as containers (sets, ordered lists, etc)
compaction of strings within the body of content
This example specifies the context inline with the other json-ld body of content in the file and is limited to only the prefixes used for the content in the file.
JSON-LD supports the specification of context inline, as a separate file referenced from the json-ld content file, or potentially a combination of both.
For consistent and more concise use of serialized UCO json-ld content by the adopting community, a full json-ld context is needed for each version of UCO that is available for remote online reference or for local deployment and reference by json-ld serialized content.
Requirements
Requirement 1
json-ld context to support compaction of all IRI base paths through defined prefixes
Requirement 2
json-ld context to support compaction of all property type assertions
Requirement 3
json-ld context to support assertion of properties with potential cardinalities >1 as set arrrays
Requirement 4
json-ld context to support compaction of json-ld specific key strings @id, @type, @value and @graph to simple json key strings id, type, value, and graph such that the body of content can be viewed as simple json and the context can be utilized to expand it into fully codified json-ld
Requirement 5
json-ld context to support compaction of class type names and property names to prefixless names where possible (where the base names without prefixes are uniquely defined in UCO). For any base name defined in UCO that is non-unique when prefixes are removed or for any custom (not defined in UCO) class types or properties defined by the content producer, the prefixed name would be used.
This requirement is only necessary for the "concise" version of the json-ld context.
Requirement 6
Ability to autogenerate full json-ld context for each UCO release
Requirement 7
Ability to autogenerate full json-ld context for any interim UCO version
Requirement 8
Ability to publish json-ld context for each UCO release online such that produced UCO content can effectively reference and use it for json-ld processing
Requirement 9
Ability for a producer to pull down an online published json-ld context and utilize it locally with their defined content
Requirement 10
Ability for UCO content producer to specify both a reference to a remote official json-ld context for UCO and a local inline json-ld context for any custom (not defined in UCO) class types or properties defined by the content producer in their content
Risk / Benefit analysis
Benefits
Consistency of serialized content produced, exchanged and consumed by UCO community adopters.
Smaller and more concise serialized UCO content.
Ability for producers to treat UCO content as simple JSON while yielding the significant benefits of JSON-LD.
Risks
All existing UCO and CASE examples should be updated to utilize the new context and compact form.
Competencies demonstrated
Competency 1
Compaction and expansion of json-ld serialized content
Competency Question 1.1
What is the fully compacted form of a given body of json-ld serialized UCO content?
Result 1.1
The fully compacted and concise form of the json-ld serialized UCO content
Competency Question 1.2
What is the fully expanded form of a given body of json-ld serialized UCO content?
Result 1.2
The fully expanded and verbose form of the json-ld serialized UCO content
Solution suggestion
Implement code to autogenerate two different (minimal and concise) json-ld contexts for any given version of UCO.
Persistently publish online the two json-ld contexts for each official release of UCO.
Temporarily publish somewhere online the two json-ld contexts for each interim version of UCO.
The "minimal" json-ld context would be considered the default and would support Requirements 1 - 4.
Using the scope of the Device example to provide an illustrative example of what such a context would like (the actual full context would contains details for ALL prefixes, and properties in UCO) the context would look something like:
Utilizing this context combined with a local in-line defined context for the custom (non-UCO defined content in the body content), the Device example content would look like this:
The "minimal" json-ld context could be created by a coding implementation of the following pseudo-code:
The "concise" json-ld context would be considered optional for those who desire a very concise form and would support Requirements 1 - 5.
Using the scope of the Device example to provide an illustrative example of what such a context would like (the actual full context would contains details for ALL prefixes, and properties in UCO) the context would look something like:
Utilizing this context combined with a local in-line defined context for the custom (non-UCO defined content in the body content), the Device example content would look like this:
Background
The chosen default serialization for UCO content is json-ld. json-ld spec
json-ld is an officially supported serialization within the RDF ecosystem and is losslessly transformable by rdf tools to other rdf serializations.
The default fully expanded form of json-ld is referred to as "expanded" and contains full IRIs for all class types and properties. Throughout this CP the "Device" example within the CASE examples repo will be utilized for illustrative purposes. CASE Device example.
In expanded json-ld form this example would look like this:
JSON-LD provides a mechanism called a "context" that allows specification of particular details that allow a related body of json-ld content to be compacted to a more concise form. It also supports any amount of lossless compaction and expansion.
The Device example as it exists in the CASE examples repo currently applies a simple json-ld context to avoid having to repeatedly express IRI path detail for every object in the content. Using this simple level of compaction yields the example in this form:
JSON-LD contexts can also support things like
This example specifies the context inline with the other json-ld body of content in the file and is limited to only the prefixes used for the content in the file.
JSON-LD supports the specification of context inline, as a separate file referenced from the json-ld content file, or potentially a combination of both.
For consistent and more concise use of serialized UCO json-ld content by the adopting community, a full json-ld context is needed for each version of UCO that is available for remote online reference or for local deployment and reference by json-ld serialized content.
Requirements
Requirement 1
json-ld context to support compaction of all IRI base paths through defined prefixes
Requirement 2
json-ld context to support compaction of all property type assertions
Requirement 3
json-ld context to support assertion of properties with potential cardinalities >1 as set arrrays
Requirement 4
json-ld context to support compaction of json-ld specific key strings @id, @type, @value and @graph to simple json key strings id, type, value, and graph such that the body of content can be viewed as simple json and the context can be utilized to expand it into fully codified json-ld
Requirement 5
json-ld context to support compaction of class type names and property names to prefixless names where possible (where the base names without prefixes are uniquely defined in UCO). For any base name defined in UCO that is non-unique when prefixes are removed or for any custom (not defined in UCO) class types or properties defined by the content producer, the prefixed name would be used.
This requirement is only necessary for the "concise" version of the json-ld context.
Requirement 6
Ability to autogenerate full json-ld context for each UCO release
Requirement 7
Ability to autogenerate full json-ld context for any interim UCO version
Requirement 8
Ability to publish json-ld context for each UCO release online such that produced UCO content can effectively reference and use it for json-ld processing
Requirement 9
Ability for a producer to pull down an online published json-ld context and utilize it locally with their defined content
Requirement 10
Ability for UCO content producer to specify both a reference to a remote official json-ld context for UCO and a local inline json-ld context for any custom (not defined in UCO) class types or properties defined by the content producer in their content
Risk / Benefit analysis
Benefits
Consistency of serialized content produced, exchanged and consumed by UCO community adopters.
Smaller and more concise serialized UCO content.
Ability for producers to treat UCO content as simple JSON while yielding the significant benefits of JSON-LD.
Risks
All existing UCO and CASE examples should be updated to utilize the new context and compact form.
Competencies demonstrated
Competency 1
Compaction and expansion of json-ld serialized content
Competency Question 1.1
What is the fully compacted form of a given body of json-ld serialized UCO content?
Result 1.1
The fully compacted and concise form of the json-ld serialized UCO content
Competency Question 1.2
What is the fully expanded form of a given body of json-ld serialized UCO content?
Result 1.2
The fully expanded and verbose form of the json-ld serialized UCO content
Solution suggestion
Implement code to autogenerate two different (minimal and concise) json-ld contexts for any given version of UCO. Persistently publish online the two json-ld contexts for each official release of UCO. Temporarily publish somewhere online the two json-ld contexts for each interim version of UCO.
The "minimal" json-ld context would be considered the default and would support Requirements 1 - 4. Using the scope of the Device example to provide an illustrative example of what such a context would like (the actual full context would contains details for ALL prefixes, and properties in UCO) the context would look something like:
Utilizing this context combined with a local in-line defined context for the custom (non-UCO defined content in the body content), the Device example content would look like this:
The "minimal" json-ld context could be created by a coding implementation of the following pseudo-code:
The "concise" json-ld context would be considered optional for those who desire a very concise form and would support Requirements 1 - 5. Using the scope of the Device example to provide an illustrative example of what such a context would like (the actual full context would contains details for ALL prefixes, and properties in UCO) the context would look something like:
Utilizing this context combined with a local in-line defined context for the custom (non-UCO defined content in the body content), the Device example content would look like this:
The "concise" json-ld context could be created by a coding implementation of the following pseudo-code:
Coordination