How to reference properties and values in JSON-LD?

I found a few examples of JSON-LD code, such as this blog article:

{
  "@context": "http://schema.org",
  "@type": "BlogPosting",
  "headline": "14 Ways Json Can Improve Your SEO",
  "alternativeHeadline": "and the women who love them",
  "image": "http://example.com/image.jpg",
  "award": "Best article ever written",
  "editor": "John Doe",
  "genre": "search engine optimization",
  "keywords": "seo sales b2b",
  "wordcount": "1120",
  "publisher": {
    "@type": "Organization",
    "name": "Elsevier",
    "logo": {
      "@type": "ImageObject",
      "url": "http://example.com/logo.jpg"
    }
  },
  "url": "http://www.example.com",
  "datePublished": "2015-09-20",
  "dateCreated": "2015-09-20",
  "dateModified": "2015-09-20",
  "description": "We love to do stuff to help people and stuff",
  "articleBody": "You can paste your entire post in here, and yes it can get really really long.",
  "author": {
    "@type": "Person",
    "name": "Steve"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/article"
  }
}

In it, you see that the @context is set, so from that context you can more concisely reference a @type called BlogPosting. Then you get direct access to using the properties in JSON.

Oh I will note, I have never used JSON-LD, just knew about it for years. I spent the past hour looking through the JSON-LD Spec, and the IRI RFC, trying to figure out how to reference properties and values from other code, and generally how to organize JSON-LD.

What does the hashtag # mean in detail in the JSON-LD?

For example, they have this:

{
  "@context": {
    "label": "http://www.w3.org/2000/01/rdf-schema#label"
  },
  "@id": "",
  "label": "Just a simple document"
}

When I visit the url http://www.w3.org/2000/01/rdf-schema, I get some raw RDF text. I see label as a property definition in the RDF, but is the context label http://www.w3.org/2000/01/rdf-schema#label just giving us a "casual" / mental association between that RDF text and our JSON-LD code? To me it doesn't seem a computer could:

Fetch the content at http://www.w3.org/2000/01/rdf-schema.
Realize it is RDF.
Parse the RDF.
Dig into the label property.
And use that to know how to type the label property in our JSON-LD.

Another example is here, using http://schema.org:

{
  "@context": {
    "name": "http://schema.org/name",   
    "image": {
      "@id": "http://schema.org/image",   
      "@type": "@id"   
    },
    "homepage": {
      "@id": "http://schema.org/url",   
      "@type": "@id"   
    }
  }
}

When I visit http://schema.org/url, it is an HTML page (not RDF or JSON), and it shows like this.

They don't appear to have a http://schema.org/url.json or .rdf URL, so again it appears this "mental association" between http://schema.org/url and an actual URL property isn't something that is processed or figured out by a computer, but is simply a rough mental association. Basically, we added the http://schema.org/url HTML webpage so if you happen to visit http://schema.org/url it shows something, and because it's nice to have some web docs :). But there's not a technical need to have a website or JSON to download for definitions or whatnot. In the end, the links like http://schema.org/url are simply strings which are used as identifiers. Am I correct in that?

Then that would mean the # hashtag like http://www.w3.org/2000/01/rdf-schema#label or others, is simply another string, but the code which compiles JSON-LD splits off the after-hashtag part and uses it to lookup and type properties in the JSON. It doesn't, however, have any real meaning as being hosted on a webpage under that domain/URL.

So say I have a bunch of URLs I want to create:

/person/john-kennedy
/atom/hydrogen
etc.

Each which has a bunch of possibly deeply-nested properties/objects/values. So could I just do:

{
  "@context": "https://mywebsite.org",
  "@type": "atom",
  "slug": "hydrogen",
  "name": "Hydrogen",
  "bindsTo": [{ "@id": "https://mywebsite.org/atom/oxygen" }]
}

Or even better, somehow do something like this:

{
  "@context": "https://mywebsite.org",
  "@type": "atom",
  "@id": "/atom/hydrogen",
  "name": "Hydrogen",
  "bindsTo": [{ "@id": "/atom/oxygen" }]
}

In short, what am I allowed to do to link data using JSON-LD in as clean a way as possible (minimal amount of text)?

Does there need to be an actual web-presence backing the actual structured JSON data, or is it just out of convention or to create a somewhat friendly user experience, but not required for the machine?
Is the hashtag just a convention for reaching into properties? Can the hashtag be used to deeply dig into properties (or array items), like #foo/bar[1]/baz which would dig into { foo: { bar: [ { baz: 1 }, { baz: 2 } ] } } to return 2? Or is the hashtag actually used by the hosting website somehow?

Solution

It is a good practice to provide the RDF definition of the vocabulary/term when resolving the term URI, but it’s not required. Not least because any kind of URI can be used for RDF terms, not only resolvable URIs (e.g., urn or tag instead of http).

There are several ways to provide the vocabulary definition in a machine-readable way. The W3C Working Group Note Best Practice Recipes for Publishing RDF Vocabularies documents some of them.

Appendix B explains the role of # (vs. /) in RDF term URIs. It’s just a way to build the URI namespace for the vocabulary (and can also be used to distinguish between the term/thing and the document where the term/thing is described).

And yes, the essential role of RDF term URIs is that they serve as globally unique identifiers.

JSON-LD is special, compared to the other RDF syntaxes, that remote JSON-LD contexts can be loaded. For example in the case of Schema.org, their JSON-LD context is linked in a Link HTTP header when accessing the front page (using the alternate link type). Such a context merely allows to write shorter JSON-LD.

This and other JSON-LD features might be confusing when learning about the Linked Data background. It might be helpful to "think" about the data in triple form. The popular RDF syntax Turtle is close to this concept. If you know how the triples should look like, it’s just a matter of using JSON-LD’s syntax features to materialize what you want to say. In many cases it’s easier to write/generate Turtle and then to convert it into JSON-LD (or any other RDF syntax) automatically.

The JSON-LD

# on https://mywebsite.example.com/
{
  "@context": "https://vocabulary.example.org",
  "@type": "Atom",
  "@id": "/atom/hydrogen",
  "name": "Hydrogen",
  "bindsTo": [{ "@id": "/atom/oxygen" }]
}

could be expressed in Turtle like this:

@prefix : <https://vocabulary.example.org/> .

<https://mywebsite.example.com/atom/hydrogen>
  a        :Atom ;
  :bindsTo <https://mywebsite.example.com/atom/oxygen> ;
  :name    "Hydrogen" .

@prefix : <https://vocabulary.example.org/> .

<https://mywebsite.example.com/atom/hydrogen> a        :Atom .
<https://mywebsite.example.com/atom/hydrogen> :bindsTo <https://mywebsite.example.com/atom/oxygen> .
<https://mywebsite.example.com/atom/hydrogen> :name    "Hydrogen" .

<https://mywebsite.example.com/atom/hydrogen> a                                        <https://vocabulary.example.org/Atom> .
<https://mywebsite.example.com/atom/hydrogen> <https://vocabulary.example.org/bindsTo> <https://mywebsite.example.com/atom/oxygen> .
<https://mywebsite.example.com/atom/hydrogen> <https://vocabulary.example.org/name>    "Hydrogen" .

<https://mywebsite.example.com/atom/hydrogen> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://vocabulary.example.org/Atom> .
<https://mywebsite.example.com/atom/hydrogen> <https://vocabulary.example.org/bindsTo>          <https://mywebsite.example.com/atom/oxygen> .
<https://mywebsite.example.com/atom/hydrogen> <https://vocabulary.example.org/name>             "Hydrogen" .