Define a recommended context to import

[azaroth42]

Instead of normatively requiring an initial context, such as RDFa does, instead JSON-LD has the ability to import contexts. This approach means that the existing context rules are followed, and the best practice context can be updated over time as new norms emerge in the community. If the best practice context is not useful to a particular community, then they don't need to import it.

To Do:

• Discuss the set of ontologies to include as prefixes
• Discuss the set of aliases and term definitions to include (e.g. id, type, label, comment)
• Create and publish context document in /ns/

[BigBlueHat]

Perhaps this is best positioned as part of the Primer/Getting Started content. I'm a bit concerned about it being too visible in the syntax spec--for fear it would get conflated with JSON-LD syntax itself.

Regardless of what this thing becomes, it should build off of the RDFa Core Initial Context.

[gkellogg]

Creating a default context could provide backwards compatibility issues, to the extent that terms which Dre previously undefined, and thus did not expand, might now be defined, leading to different results. Probably not a show-stopper.

[iherman]

I am not sure yet whether this can be done (e.g., due to backward compatibility), but maintaining some sort of a 'best practice context' would already be very helpful (although people would have to explicitly import it). Note that there is a JSON-LD version of the RDFa Core Initial Context (maintained by yours truly) at https://www.w3.org/2013/json-ld-context/rdfa11 (although it is a bit of a misnomer).

Some experiences on the RDFa context might be helpful.

• It is an old-skool setup, which relies on a central person to be maintained (i.e., the W3C Team, currently me). Times have changed, and a similar JSON-LD initiative should probably be on github, with the community making PR-s for proposed changes (which can only be additions) and with a number of people having the right to merge. The current dependency on, essentially, me is a very weak point for RDFa. (I just realized that I have forgotten to add ODRL, shame on me, but nobody protested!)

• It also has the obvious disadvantage that all RDFa implementations must be updated, and I am not sure they actually do and whether people really rely on it. Of course, this is not a problem with JSON-LD, which is a huge difference.

• The real question is: what should be the content? At the moment, the policy is:

  1. any vocabulary defined by a stable W3C document
  2. use the widely used vocabularies and/or terms

  while I think (i) is fine, (ii) is of course very difficult to measure. Back in the RDFa days we got some help from Yahoo and, if I remember well, Sindice, to give us some numbers on what the widely used vocabularies were at the time. We came up with a result which, to be fair, nobody contested. (We manually added schema which, at the time, was still in its infancy, but we knew it would be widely used.)

  The idea was that we would do this type of measurement regularly to update the content. It never happened, also due to the demise of Yahoo and Sindice...

I guess we may start by accepting the content of the RDFa initial context, although I am not sure about role as term, though, I do not think anybody uses that entry; neither am I sure about describedBy. I am also not sure about the Good Relations vocabulary, because GR has been transposed to schema.org. Some others may have come to the fore since.

We could then release it on a separate github repo (with a W3C URL redirected to the file) and see if the community wants to add anything.

[pchampin]

I was not aware of that RDFa core context (shame on me), but that's awesome!
Big +1 to what Ivan proposes -- except may be that I have the gut feeling that some form of deprecation should be possible.

Also, I think that memorizing this context's IRI should be effortless (alla "https://schema.org" – and yes, I'm looking at you, rdf:!!). So an alias in the W3C namespace might not be the ideal solution...

[iherman]

Note that the schema.org context file also includes some terms:

xml: "http://www.w3.org/XML/1998/namespace",
foaf: "http://xmlns.com/foaf/0.1/",
eli: "http://data.europa.eu/eli/ontology#",
snomed: "http://purl.bioontology.org/ontology/SNOMEDCT/",
bibo: "http://purl.org/ontology/bibo/",
rdfs: "http://www.w3.org/2000/01/rdf-schema#",
skos: "http://www.w3.org/2004/02/skos/core#",
void: "http://rdfs.org/ns/void#",
dc: "http://purl.org/dc/elements/1.1/",
dctype: "http://purl.org/dc/dcmitype/",
rdf: "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
dcat: "http://www.w3.org/ns/dcat#",
rdfa: "http://www.w3.org/ns/rdfa#",
xsd: "http://www.w3.org/2001/XMLSchema#",
schema: "http://schema.org/",
dct: "http://purl.org/dc/terms/",
dcterms: "http://purl.org/dc/terms/",
owl: "http://www.w3.org/2002/07/owl#",
xsd1: "hhttp://www.w3.org/2001/XMLSchema#",

If we do this, we must be compatible as much as we can. (There are major overlaps with the RDFa version.)

[iherman]

Also, I think that memorizing this context's IRI should be effortless (alla "https://schema.org" – and yes, I'm looking at you, rdf:!!). So an alias in the W3C namespace might not be the ideal solution...

Well… the problem is that if we get ourselves a separate domain, we are bound to problems sometimes down the line, insofar as somebody has to keep that domain, and the relevant site, alive. I do not think we should do that; stability requires to bind this to some domain that will survive us (or, to be less dramatic, survive all of us changing work, retire, etc. :-). This leaves us with the w3c domain, which (with the internal rules of W3C) leaves us with something like https://www.w3.org/ns/XYZ.

[dlongley]

I'd rather see a recommended context in a best practices/primer/getting started doc as @BigBlueHat suggests. Even then, I'm not convinced there is such a context that broadly supports enough use cases to fill that role (unless it's either pulling in the world like schema.org does or it's quite limited). Lastly, I would prefer that we strongly encourage the use of regular terms over the use of CURIEs -- which may fly in the face of what's being suggested here, I'm not sure.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward “bare” (non-CURIE’d) terms
• RESOLVED: have ivan setup initial repository for publishing a “common” context featuring prefixes and “bare” terms for use in the Best Practices document (and beyond)
• ACTION: set up an initial repository for a common context (Ivan Herman)

View the transcript

Recommended base context
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/59
Simon Steyskal: bigbluehat: feature freeze was not regarding the primer document
Rob Sanderson: Issues for today about the primer document, so not subject to feature freeze
Benjamin Young: Idea is to have a default context, similar to RDFa. Discussion about the risks and concerns, mostly about backwards compatibility
… should it be a best practice / prevailing pattern. Make these available, as a lot of content is in these namespaces
… dlongley raised that keys not curies are a good pattern
… repeating common prefixes makes sense.
Ivan Herman: need to be a little bit careful with rdfa comparison. It had the extra difficulty of not having an equivalent of importing a file with prefixes
… so supposed to put everything in your document, which becomes a pain
… so default for RDFa is important. We don’t have that difficulty.
… Can import context file, so the load is not the same. Building in an automatic mechanism for these prefixes may not be a good idea;
… in the RDFa case, the consequence is that every implementation has to regularly update their defaults
… when the defaults are changed. E.g., writing my comments, I forgot to add something into my implementation, so updated it this morning. A pain on implementers and users of those implementations
… I think that having an automatic mechanism is not a good idea, but having a context in a well known place with a number of useful things, and is maintained by the community via GH, is a good idea
Rob Sanderson: +1 to Ivan
Pierre-Antoine Champin: +1 to not make it automatic
Ivan Herman: what this context should contain is a separate discussion
… not really agreeing with dlongley. The number of vocabs in RDFa is quite extensive, so flattened would become a problem, and there would be a clash
… in favor of reproducing the rdfa stuff. If people don’t like CURIEs they don’t have to use it
Pierre-Antoine Champin: totally agree with ivan. dlongley’s concern is orthogonal to this. This context is useful for more RDF-y, and don’t mind CURIEs. Also to context designers, for a base to import
… to not worry about the prefixes, in order to define the flat namespace
Rob Sanderson: +1 to pchampin!
Benjamin Young: +1 to having a handy context for common namespaces
Benjamin Young: I don’t think dlongley was suggesting we discourage curies, but that the prevailing pattern is that communities publish their own context, with imports
… at the data document level, discouraging curies is fine… but as pchampin pointed out it looks normal for some communities
… so having a context with common mappings and making it available to import would be nice
… process wise we need to decide how to maintain it
… could be in the primer, but not extractable
Ivan Herman: I think you are right — copy/paste is not the right solution. We can set up a mini repository that contains that stuff and the readme
… need to agree on a URL to be put somewhere, w3/ns could work
… would then redirect to the GH document
… for a start that would be okay, then need to see once the WG is done, then the CG could take over
… and would have the right to decide on PRs and so on
… whether it’s on json-ld or not … it doesn’t really matter
Benjamin Young: question of URL simplicity, but related to the process
Ivan Herman: No problem with it, but i don’t know who maintains json-ld.org the domain and if it will be still around
… in W3C URL space it’s not our problem
Rob Sanderson: I agree with Ivan that a W3C url is less worry about maintaining domain names.
Pierre-Antoine Champin: … There is prior art in maintaining a namespace at W3C. We can do the same.
Benjamin Young: The activity streams space is now maintained by the CG. They have additive process for getting stuff into it
… some more prior art there
… The CORS issues also highlights the need for stability
Proposed resolution: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward “bare” (non-CURIE’d) terms (Benjamin Young)
Simon Steyskal: +1
Jeff Mixter: +1
Harold Solbrig: +1
David I. Lehn: with common resources need to consider caching issues so as to not overload servers
Adam Soroka: +1
Pierre-Antoine Champin: +1
Rob Sanderson: +1
Benjamin Young: +1
Ivan Herman: +1
Resolution #3: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward “bare” (non-CURIE’d) terms
Ivan Herman: I would propose to create a separate repository that will have a readme and a json context file, and redirect from a /ns/ name
… as a first approximation, for something to talk about, there is already a context file that was set up some time ago that mimics the RDFa defaults
… I would take that and put it up, and we can discuss what should be in it
Benjamin Young: What if we were to make this a shared effort to build off the RDFa one, to make it more operationalized
… it exists, we could make it less brittle
Ivan Herman: do you mean we do this together with the RDFa file?
Benjamin Young: yes, create the repo and process and make that happen using the existing RDFa file. New process would then maintain it, and strengthen the one that’s there
… good to not have two that are 99% the same
Rob Sanderson: it seems like there will be things we’d like to do in a context, which won’t be possible in RDFa
… so they’d be related, but different
… like we might want “label” as a bare term in the default context
… or @id to id, and @none to none, etc
… those make no sense in RDFa
Benjamin Young: …so, like where this is headed, but the specific documents would need to be separate
Ivan Herman: Agree, to add to it, the way the RDFa doc was created I’ve described in the issue, but worth looking at the document critically and see if it’s still relevant
… Another aspect to it
… merging is risky, and may create problems
… keep them separate, and w3c’s problem to maintain the RDFa doc
Benjamin Young: Good points about different needs. Want the prefixes to match, and to stay matching.
… We use them together, so lean on the RDFa doc quite a bit
… Should be as stable and maintained as possible
Pierre-Antoine Champin: I spotted a discrepancy btw schema.org and RDFa with dublin core
Ivan Herman: Prefixes should be the same, as much as possible. Will need to check, eg that schema.org does the same thing, with a smaller set of prefixes. The schema.org context file has foaf, and there should be compatibility there. If there’s a clash, we should be in favor of schema?
… but I’ll set up the initial thing. We can come back and look at it
Proposed resolution: have ivan setup initial repository for publishing a “common” context featuring prefixes and “bare” terms for use in the Best Practices document (and beyond) (Benjamin Young)
Ivan Herman: +1
Rob Sanderson: +1
Jeff Mixter: +1
Pierre-Antoine Champin: +1
Benjamin Young: +1
Adam Soroka: +1
Simon Steyskal: +1
Harold Solbrig: +1
Resolution #4: have ivan setup initial repository for publishing a “common” context featuring prefixes and “bare” terms for use in the Best Practices document (and beyond)
Action #1: set up an initial repository for a common context (Ivan Herman)
David I. Lehn: I wasn’t sure how to vote on those proposals. will need to consider proper versioning and caching to make shared resources work. already an issue with similar things at w3id.org. but perhaps making a common context is a good experiment that will force related best practices to be developed.
Ivan Herman: in the mean time … bikeshed … but what URL for /ns ?
Benjamin Young: Let’s do that on the GH repo :)

[iherman]

As agreed on the last call, I have created the separate repository:

• https://github.com/w3c/json-ld-rc

which now contains an initial recommended context. I have started with the RDFa initial context, though I have not added all the terms, and I have also made a change on one of the terms. I have also made some basic synchronization with the schema.org context. I have described all these changes on a separate wiki page on the repo; reviews are not only welcome but necessary…

I haven't yet installed a redirection from https://www.w3.org/ns/…; should be done if we have a stable content and a name for the public URL...

[iherman]

@gkellogg @azaroth42 @BigBlueHat @dlongley do we want to pursue this line? If so:

1. we have to agree on a name for the context.
   • just to start bikeshedding, what about: https://www.w3.org/ns/basic-context
2. I would have to set up the necessary redirections to https://github.com/w3c/json-ld-rc/blob/master/context.jsonld
3. We have to agree on the content of that json context...

[pchampin]

Athough I was not explicitly asked ;-)

do we want to pursue this line?

I'd say yes.

And to reply to @dlongley's concern about favoring regular terms over CURIEs, I'd argue that such a context would still be valuable for context authors. E.g.:

{ "@context": [
    "https://www.w3.org/ns/basic-context",
    {
        "name": "schema:name",
        "born": {
            "@id": "schema:birthDate",
            "@type": "xsd:date"
        }
    }
]}

[iherman]

@pchampin I should have asked you explicitly...

Maybe an extra agenda topic for today, @azaroth42 @BigBlueHat ?

[iherman]

This issue was discussed in a meeting.

• RESOLVED: We will produce a baseline context that provides some degree of general utility
• RESOLVED: baseline context should contain (at least) all of the aliases from the best practices (eg id: <code>@id)</code>
• RESOLVED: Explore which other definitions are widely used and include in baseline (sic) context
• ACTION: update json-ld vocabulary at ns/json-ld (Gregg Kellogg)

View the transcript

toolkit [bikeshed] context
Ivan Herman: Recommended context: https://github.com/w3c/json-ld-rc/blob/master/context.jsonld
Rob Sanderson: #9
Ivan Herman: I setup this stuff months ago, I even forgot about it.
… Do we want to do it or not?
… We may decide to drop it. But we need to decide.
… I called it a recommended context.
Gregg Kellogg: We approached things like this in the past. There is a CSVW context.
… We have a couple of contexts that ivan needs to maintained, so if we just have a base jsonld context, those can refer to this base context, which would simplify maintenance.
Ivan Herman: To be honest, I don’t really maintain the CSVW context anymore.
… All of these things eventually end up with one responsible person, who may go away eventually, and it dies.
… This is my worry with that.
Gregg Kellogg: https://www.w3.org/ns/csvw.jsonld
Ivan Herman: I do still maintain the RDFa one.
… If I leave W3C, I doubt anyone will do anything with it.
… I’m neutral about this.
Rob Sanderson: I think it’s useful, even if it becomes static in the long term.
… At least in the meantime the systems that point to it have some advantage.
… It is an encoding of the best practices.
… It includes the aliases that we recommend, so users get that for free.
… If a future WG want to add their NS to that context, they are free to do so.
… If there is a jsonld 2.0, we may want to add new entries to the context for that era.
… I’d like to go ahead with it.
Adam Soroka: If we want to minimize maintenance, we could have a more minimal context that includes some aliases, but does not include namespaces.
… This would not require (as much) updates.
Rob Sanderson: We could have two contexts: one with aliases based on BP, and one including the namespaces.
Gregg Kellogg: https://www.w3.org/ns/json-ld
Gregg Kellogg: We also have a jsonld NS document, which references a jsonld and ttl version.
… It was put in place to define a jsonld context, so we can define a jsonld context in RDF.
… This vocab probably needs some work.
… The issue with this doc is that the links to jsonld and ttl are missing.
… If you give me an action, I can update this document.
Action #1: update json-ld vocabulary at ns/json-ld (Gregg Kellogg)
Gregg Kellogg: In this RDF document, the data model of a context is defined.
… One may think that this is a natural place to look for a default jsonld context.
Ivan Herman: This is already a pretty sizely thing. I’m afraid that it may become too large.
… I would not give that out as a BP thing. I would keep them separate.
… The list of NS that is there comes from the RDFa stuff. I didn’t make a choice of what we should keep or not. There are some vocabs there that are pretty rarely used, or focused used?
Ruben Taelman: s/?/./
Ivan Herman: I would just keep a couple of them.
… But this is personal.
… Either we keep it as-is, or we remove namespaces and just keep aliases, labels, comments, licenses.
Proposed resolution: We will produce a baseline context that provides some degree of general utility (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Jeff Mixter: +1
Tim Cole: +1
Pierre-Antoine Champin: +1
Ruben Taelman: +1
Ivan Herman: +1
Resolution #10: We will produce a baseline context that provides some degree of general utility
Adam Soroka: +1
Ivan Herman: Now what does it contain?
Gregg Kellogg: With a GH redirect, we can finese that over time.
… Where should it live?
Ivan Herman: What should it be called?
Rob Sanderson: Where does it live, what is it called, and what does it contain?
… We agreed that it should at least contain all the aliases from the BP.
Proposed resolution: baseline context should contain (at least) all of the aliases from the best practices (eg id: @id) (Rob Sanderson)
Pierre-Antoine Champin: We have an @json keyword, and we don’t have an alias for it.
Ivan Herman: We have some shortnames for datatypes.
Gregg Kellogg: In BP, we talk about aliasing keywords. So it makes sense to also have the json alias.
… We could have capital json vs lowercase json, but that may make it confusing.
Ivan Herman: So I should add an json->@json alias.
Gregg Kellogg: JSON => rdf:JSON, json => @json
Pierre-Antoine Champin: There are two aliases that may be confusing. Anywhere the @json keyword can appear, the rdf:JSON would work too?
Gregg Kellogg: Not really, @json is used for marking a value as things that should be interpreted as JSON instead of JSON-LD.
Proposed resolution: baseline context should contain (at least) all of the aliases from the best practices (eg id: @id) (Rob Sanderson)
Ruben Taelman: +1
Rob Sanderson: +1
Gregg Kellogg: +1
Tim Cole: +1
Pierre-Antoine Champin: +1
Ivan Herman: +1
Adam Soroka: +1
Resolution #11: baseline context should contain (at least) all of the aliases from the best practices (eg id: @id)
Ivan Herman: There are also currently some terms that we defined (outcome of earlier comments): license, label, comment.
… There is an RDF term for this, so we can just use that.
… I believe these three are things that we should keep.
… I am less sure about isDefinedBy and …
… Both label and comment are strings I think.
Gregg Kellogg: I don’t think their range is defined even.
Rob Sanderson: In IIIF we said that labels should be strings.
Pierre-Antoine Champin: I’m pretty sure I saw both xsd:strings and LanguageStrings used with rdfs:label
Gregg Kellogg: Both have rdfs:Literal as range.
Rob Sanderson: We can redefine the default, but given I18N, we should say that a label should handle languages.
Ivan Herman: Yes, we should use I18N strings.
Tim Cole: I’m concerned that not everything is essential for everyone. We may be getting ahead of ourselves.
… Some people may pickup the context, and may not realize aliases that are defined, and may be unaware of clashes.
Proposed resolution: Explore which other definitions are widely used and include in baseline (sic) context (Rob Sanderson)
Tim Cole: +1
Rob Sanderson: +1
Ruben Taelman: +1
Jeff Mixter: +1
Ivan Herman: +1
Pierre-Antoine Champin: +1
Gregg Kellogg: +1
Adam Soroka: +0
Resolution #12: Explore which other definitions are widely used and include in baseline (sic) context

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Base Context
Rob Sanderson: #9
Rob Sanderson: https://github.com/w3c/json-ld-rc
Rob Sanderson: https://github.com/w3c/json-ld-rc/blob/master/context.jsonld
Rob Sanderson: the dedicated repo has one issue, requesting reviews on its content
… This document lists core aliases and core prefixes.
… Please review if before next week, and raise any issue for missing terms,
… or the way the context is defined.
Ivan Herman: One radical way of doing it is to put in the BP document this context with only the aliases,
… and leave aside the prefixes, which will raise the issue of “why this one and not that one”.
… Arguably, a few of them (rdf, owl) could be kept,
… but they are only used by RDF geeks who know what to do.