w3c / json-ld-rc

JSON-LD Recommended Context

RDFa Core Initial Context, JSON-LD Recommended Context

This is the repository for a recommended context for JSON-LD 1.1, as well as the RDFa Core Initial Context, developed and maintained by the W3C JSON-LD Working Group. Most of the major resources in this repository are redirected from W3C URI-s that have been in use by the community for a while. These are as follows:

• RDFa Core Initial Context: a list of predefined prefixes defined for RDFa as an “initial context”. RDFa users can use these prefixes without having the obligation of defining the prefixes in the HTML code, because RDFa implementations are supposed to “know” these prefixes. The list of these prefixes are available in:

  • HTML+RDFa, redirected from https://www.w3.org/2011/rdfa-context/rdfa-1.1.html
  • Turtle, redirected from https://www.w3.org/2011/rdfa-context/rdfa-1.1.ttl
  • RDF/XML, redirected from https://www.w3.org/2011/rdfa-context/rdfa-1.1.rdf
  • JSON-LD, redirected from https://www.w3.org/2011/rdfa-context/rdfa-1.1.jsonld

  Note the the https://www.w3.org/2011/rdfa-context/rdfa-1.1 URI can be used and the format is returned based on context negotiation.

• JSON-LD Recommended Context: the list of prefixes, defined by the RDFa initial context, is also available as a JSON-LD @context file. JSON-LD users can use these prefixes by referring to this recommended context by importing it through a @context statement. This context file is available in:

  • JSON-LD Context, redirected from http://www.w3.org/2013/json-ld-context/rdfa11

• Turtle prefixes: the list of prefixes, defined by the RDFa initial context, is also available as a Turtle file. Turtle does not have any import mechanism, but this file can be imported manually into a Turtle file. This turtle file is available in:

  • Turtle prefixes (no redirection from w3c.org is provided)

Automatically Derived Files

On a pull request, the files in Turtle, RDF/XML, and JSON-LD syntaxes are all built from the RDFa Initial Context in rdfa-1.1.html. Those files should not be modified by hand.

Files are built using a GitHub Workflow using a series of Ruby scripts to generate the associated files. The workflow is started when a Pull Request is created or updated.

Contributing to the Repository

Use the standard fork, branch, and pull request workflow to propose changes to the content. Please make branch names informative—by including the issue or bug number for example.

Please read CONTRIBUTING.md, about licensing contributions.

Code of Conduct

W3C functions under a code of conduct.

json-ld-rc's Issues

@prefix: true

The prefixes should be explicitly prefixes.

Context architecture - patterns and antipatterns, or convenience packages?

Struggling to understand why context documents seem to be ad-hoc mixtures of common terms from various vocabularies without some overarching rationale for this pattern.

I would expect and hope (and publish!) contexts that match the governance domains of the underlying vocabularies - hence a context for DCTerms, one for SKOS, etc.

This doesnt preclude creating minimal bundles of bits of these such as the recommended context for RDFA, - to express specific profiles of the underlying vocabularies for use in a given appkication domain, but cannot this be made explicit? And what can we do to have canonical, normative contexts for the same ontology building blocks we use for data models?

Split prefixes and aliases

So they can be imported separately.

Plus a wrapper that imports them both, that can be imported if both are wanted.

Review the initial content...

See separate notes on the initial content.

Trimming the context

Looking at the current context file with a critical eye, I would consider really trimming it considerably.

The choice of the RDFa default context was motivated by the lack of a @context-like mechanism in RDFa, meaning that all RDFa usages presupposed a load of repeated prefix statement (which are also awkward in RDFa). The rules to establish the RDFa context were:

1. we performed a search over the vocabulary usage at that time and chose the top ones
2. we established the rule whereby all vocabularies defined at W3C via a WG or an IG would be automatically added to the list.
3. we never remove anything from the list

Mainly (1) above is of course questionable for everyday usage: ssn, time, og, snomed may all be questionable in view of JSON-LD usage. snomed, for example, is of a very specific usage (although important in a narrow area), and I am not sure it should be part of a generic thing.

At this moment, my preferred approach would be to greatly reduce the prefixes. I would retain only the following:

        "dc": "http://purl.org/dc/elements/1.1/",
        "dc11": "http://purl.org/dc/elements/1.1/",
        "dct": "http://purl.org/dc/terms/",
        "dcterms": "http://purl.org/dc/terms/",
        "dctype": "http://purl.org/dc/dcmitype/",
        "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
        "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
        "schema": "http://schema.org/",
        "xsd": "http://www.w3.org/2001/XMLSchema#",

reasons: DC and schema are the only really ubiquitous vocabularies out there, and the rdfs+rdfs+xsd are part of the 'core' anyway. Note that I do not even include 'foaf' and 'owl'; I am not sure 'foaf' is used by anyone except by the die hard semantic web people, and the same holds for OWL.

Remove the aliases

Naming things is hard. 😉 Let's not run a fowl of existing data projects by squatting on their namespaces.

We should remove the existing aliases, and possibly move them into a separate aliases context file (for those who know what they're doing and still want them):

json-ld-rc/context.jsonld

Lines 3 to 8 in 5718ac0

	"type": "@type",
	"id": "@id",
	"none": "@none",
	"language": "@language",
	"direction": "@direction",
	"json": "@json",

Minimal vs RDFa context

Can we provide both via the same layering approach in #4?