Define a recommended context to import about json-ld-bp HOT 14 OPEN

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...

from json-ld-bp.

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.

from json-ld-bp.

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.

from json-ld-bp.

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.

from json-ld-bp.

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...

from json-ld-bp.

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.)

from json-ld-bp.

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.

from json-ld-bp.

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.

from json-ld-bp.

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)

from json-ld-bp.

@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...

from json-ld-bp.

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"
        }
    }
]}

from json-ld-bp.

@pchampin I should have asked you explicitly...

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

from json-ld-bp.

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)

from json-ld-bp.

This issue was discussed in a meeting.

• No actions or resolutions

from json-ld-bp.