Actually... for historical reasons the mapping of 'license' is to http://www.w3.org/1999/xhtml/vocab#license. I wonder whether, these days, http://schema.org/license is not more appropriate.

Another minor things that I forgot to add above: these days http://schema.org is automatically moved to https://schema.org. Should we use https instead of http?

@iherman here's the guidance from Schema.org https://schema.org/docs/faq.html#19

So...sure. 😃 Would've been nice if the world had come at securing HTTP a different way than changing protocols... https://www.w3.org/DesignIssues/Security-NotTheS.html (we needed the security, not the extra letter).

But that 🚢 has definitely sailed. 😉

Generally I'm beginning to feel like all the aliasing (which goes well beyond just JSON-LD core terms) is creating a sub-language/style of JSON-LD which is increasingly idiosyncratic. It goes well beyond the basic prefixing that the RDFa initial context does--which only includes the aliasing of 3 "bare" terms: describedby, license, and role.

This feels very much like it's own animal now... 🐱

@iherman here's the guidance from Schema.org https://schema.org/docs/faq.html#19

that faq item says "This is a lengthy way of saying that both 'https://schema.org' and 'http://schema.org' are fine". I am not sure it gives us a clear answer to my original question. Maybe the answer is "ain't broken don't fix it", i.e., leave it as http. WDYT?

I'd think at this point we should encourage the use of https://schema.org for safer context dereferencing. However...that does rename stuff and could cause issues with equivalency in people's datasets... Maybe we can sameAs these universally somewhere? 😜

Verifiable Credentials uses https://schema.org/ fwiw: https://www.w3.org/TR/vc-data-model/#example-41-a-credential-uniquely-identifying-a-subject

Verifiable Credentials uses https://schema.org/ fwiw: https://www.w3.org/TR/vc-data-model/#example-41-a-credential-uniquely-identifying-a-subject

Yep, and so does the publication manifest.

However... if we switch to https, then this should probably be done in the JSON-LD specs as well, for consistency. (And probably in the test files...)

Strongest of 👎s to https. All of the examples in the schema.org site use in the context document a @vocab of "http://schema.org/" (e.g. https://schema.org/Action), the faq entry notwithstanding about their intent (but no action?) to move to https. Thus in their markup examples, the predicates are all http, not https. [Edit to reflect vocab, not context location]

It's not at all helpful to swim against the current here.

Agree with inclusion of graph and included. But I disagree with the removal of none and json. All of these are used in compacted documents, which is the main utility of having them aliased.

For example: https://iiif.io/api/presentation/3.0/#44-language-of-property-values has none aliased to @none. Having type: json, value: "{...}" is similarly much more readable.

Conversely, @list, @set, @nest are not used in compacted documents and thus don't need to be aliased in a context.

If we keep json (which is fine with me) do we create a possible problem by having both json (aliased to @json) and JSON (aliased to rdf:JSON)?

Just wondering...

I wondered about that too. Technically no, as json and JSON are different values ... but they have the same usage. I would probably remove JSON as our examples all use the @json form rather than the CURIE form, but no strong feelings either way.

I have made some tiny changes on where I feel we have consensus; maybe we can get all this finalized on our meeting tomorrow. Here is where we are now:

1. the set of prefixes are dc11, dcterms, dctype, rdf, rdfs, schema, and xsd, with schema mapping on http.
2. the set of aliases are direction, graph, id, included, json, language, none, and type.
3. the two specific types are HTML and JSON, mapping on rdf:HTML and rdf:JSON, respectively.
4. the set of specific, pre-defined terms are: comment, label, license, isDefinedBy, seeAlso, with licence mapping on schema:license.

Here is my assessment on the four items, based on the discussions so far:

• I believe we have a consensus on (1)
• I believe we have a consensus on (2) (with @BigBlueHat and myself grudgingly accepting the fact of having aliases:-)
• The usage of JSON (as opposed to (json)) may be problematic, and @azaroth42 (in agreement with @gkellogg) proposed to remove it altogether. I am fine with that and, furthermore, I would actually propose to remove HTML, too; I would think this term would be very rarely used in JSON-LD anyway, and the rdf prefix makes an easy one to write in curie.
• I believe having license is very useful for obvious reasons; label and comment are important, due to the missing annotation facilities in JSON-LD. isDefinedBy and seeAlso may also be useful for the same reasons as label and comment, but I am actually less convinced. But I do not think it creates any harm keeping them.
• @BigBlueHat refered to describedby and role. The former could be seen as an alternative to isDefinedBy but less formal (which may be a good thing), ie, it may be a good replacement or addition. role, I believe, was added as target for the mapping of the role attribute in HTML, I am not sure we should have it here.

I'm still not OK with the aliases...and would still like to get a vote had on whether we pull those out as a separate context file.

Can we clarify who this "recommended context" is for?

It can't be for existing JSON API's--as those already have existing semantics with which these will conflict. It isn't really helpful for context authors either, unless they really do want all those things and are confident they won't have to rename them. And (which is probably the worst), if they do rename them, then there was really no point in our encouraging a shared set of aliases to begin with--because you can't depend on them "ecosystem-wide" because folks will (likely) rename them. 😢

Here's some "found JSON" (from someone else's API I'm working with):

{
  "data": [
    {
      "id": "...uuid1...",
      "type": [
        {
          "id": "...uuid2...",
          "value": "Application"
        }
      ]
    }
  ]
}

Adding the recommended context immediately throws this error:

jsonld.SyntaxError: Invalid JSON-LD syntax; "@type" value must a string, an array of strings, an empty object, or a default object.

And there's no way around that without reshaping the data (afaict).

Additionally, none of those id values are currently URLs nor do they share the same base URL, so using @base would be wrong--or at least alter the shape of the API.

Additionally, if an @base were added as a second context, all the type values (if they were changed to work) would now in that namespace...so the developer (who's quickly becoming a context file author) would need to add @vocab to separate them.

In the end, the developer will need to learn JSON-LD itself--presumably from examples and/or the Syntax doc. They will have to write some amount of context file or object, and when they attempt to do that (and learn from examples) they won't see any of these aliases. If those aliases conflict with their intended use (as http://schema.org/language conflicts with @language currently), they'll have to make and informed decision about which to pick and understand those ramifications. But if they've just grabbed the recommended context off the shelf...they'll have a much harder time learning and making the necessary changes to undo the recommendations. Which ultimately means the recommended context becomes a cost to them, not a value add.

So...if there's someone else this is for, we should define that, so we can hit that target. 😃

Regardless, I'd like to vote on at least moving the aliases into their own context file.

(I'm also happy...but confused...that we didn't also alias value to @value...but lets not do that regardless). 😉

It can't be for existing JSON API's--as those already have existing semantics with which these will conflict. It isn't really helpful for context authors either, unless they really do want all those things and are confident they won't have to rename them.

As a context author, I disagree here. This is very useful for several reasons:

1. It prevents me having to define all these things by hand in my contexts.
2. It sets expectations in the community when they see the use of the base context that the current one has been thought through and designed with the environment in mind, not just automatically or haphazardly thrown together.
3. It demonstrates that as a context author, I have taken concrete action to understand and follow best practice guidelines of the W3C.
4. If there are new entries in the base context, which we trust the W3C process to maintain in a backwards-compatible fashion, then they will become available to users of my context without any action taken by me. I can delegate the need to keep up to date with foundational ontologies and patterns up the chain.

They will have to write some amount of context file or object, and when they attempt to do that (and learn from examples) they won't see any of these aliases.

Yes. If you're writing a context and include the base context, then you hopefully have looked at what that context defines!

I don't believe that this context is useful for people who don't understand what they're doing, but I don't believe that any context would be. Nor would people who don't understand what contexts are even know or want to look for a base context... the set of people who would successfully add and use a context and not understand what it is is an empty set.

Thus we are providing a set of common, best practice definitions as a machine-usable document rather than an HTML file and requiring those aliases to be cut and paste everywhere. Given context caching, the improvement for doing this is actually non-zero in a distributed system, as demonstrated by Gregg's recent work in PyLD where context caching generally made a 50x speed improvement!

The core ask--which I think we should narrow this down to--is pulling the top-level names into their own aliases context file.

JSON-LD uses the @ prefix for its stuff on purpose--to avoid conflicts with existing JSON and to make it easy to mix in as needed/wanted.

In communities of practice (like IIIF or similar) aliasing things is totally fine--and indeed, probably recommended! But it would be naive to think that we can (or should!) determine those "meanings" for the world at large. And...again...this is why JSON-LD uses the @ prefix in the first place...

So, the practical ask again is to vote on pulling aliases into their own context file--for use by whoever wants them. No more, no less. 😄

This issue was discussed in a meeting.

• RESOLVED: the set of prefixes are dc11, dcterms, dctype, rdf, rdfs, schema, and xsd, with schema mapping on http
• RESOLVED: Remove the datatypes HTML and JSON from the context
• RESOLVED: JSON-LD Maintenance Group to take over the RDFa Initial Context work and maintain it and it’s context file via GitHub
• ACTION: move rdfa initial context (Ivan Herman)

In view of the resolutions of 2020-05-01 closing this PR without any further actions