Does JSON-Ld Have to Be Embedded

Does JSON-LD have to be embedded?

If you are using the script element as data block, "the src attribute must not be specified".

If the script element is not used as data block, it has to be "used to include dynamic scripts". But a JSON-LD document is not a dynamic script.

For linking to another resource, just like you do it with external stylesheets or Favicons, you can use the link element in the head (or the corresponding HTTP header):

<link href="/myid123/jsonld.js" rel="alternate" type="application/ld+json" />

In principle, consumers could follow this reference (possibly only if a certain link type is specified), and make use of data, just like they do it with embedded JSON-LD, Microdata, or RDFa.

However, consumers don’t have to do this, of course, and many probably don’t.

Google Search in particular does not claim to support it for consuming Schema.org in the JSON-LD format. However, they claim to support "dynamically injected" JSON-LD data blocks.

JSON-LD framing does not embed child elements

Your frame doesn't specify a @context and therefore contains does not have any semantic meaning.

A class is related to the ontology by http://www.w3.org/2000/01/rdf-schema#isDefinedBy. So if you want to have a document with Ontology on top level, and all classes defined by it nested via "contains" keyword, you have to use this frame:

{
  "@context": {
    "@vocab": "http://www.w3.org/2002/07/owl#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "contains": {
      "@reverse": "rdfs:isDefinedBy"
    }
  },
  "@type": "Ontology",
  "contains": {}
}

Permalink to the playground showing this in action.

Any example implementation JSON-LD document on a web page

In this Google Webmaster Tools Answer it says:

The data, enclosed within the <script type="application/ld+json"> ... </script> tags as shown in the examples below may be placed in either the <HEAD> or <BODY> region of the page. Either way, it won’t affect how your document appears in users’ web browsers.

I wrapped your script above in <html><header> tags and it worked with the Google Email Markup-Tester, although for some reason the Google Webmaster Structured Data Testing Tool doesn't pick up JSON-LD yet.

You can also use Google's Structured Data Markup Helper, enter some dummy URL or HTML, click "Start Tagging" (blue button), add at least one tag, then "Create HTML" (red button) and finally change the "Microdata"-dropdown to "JSON-LD".

Can you use HTML entities in JSON-LD?

Using entities is fine in embedded JSON-LD, as it is still a valid JSON string, however do not expect the entities to be replaced with their UTF-8 equivalents. As described in Section 7.2 of the JSON-LD Syntax spec

Authors should avoid using character sequences in scripts embedded in
HTML which may be confused with a comment-open, script-open,
comment-close, or script-close.
NOTE
Such content should be escaped as indicated below, however the
content will remain escaped after processing through the JSON-LD API.

This is an HTML processing rule for data script elements, and not specific to JSON-LD.

Schema.org - JSON-LD - Where to Place?

From the perspectives of Schema.org, JSON-LD, and the possibly extracted RDF, it should not matter. The data is the same, no matter from where in the document it got extracted.

From the perspective of HTML5:

If it’s data about your page (or what this page is about), you could place the script element in the head, as the head element

[…] represents a collection of metadata for the Document

But of course it would not be wrong to use body for this instead. It’s just that you shouldn’t use head for data that is not about your page or what it represents.

Duplicate or link to WebSite JSON-LD?

Do I need to declare the WebSite on every page, or can I place it once on the home page?

From the perspectives of Schema.org and Linked Data, it’s perfectly fine (and I would say it’s even the best practice) to provide an item only once, and reference it via its URI whenever it’s needed.

In JSON-LD, this can be done with @id. For example:

<!-- on the homepage -->
<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "WebSite",
  "@id": "http://example.com/#site",
  "hasPart": {
    "@type": "WebPage",
    "@id": "http://example.com/"
  }
}
</script>

<!-- on another page -->
<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "WebPage",
  "@id": "http://example.com/foobar",
  "isPartOf": {"@id": "http://example.com/#site"}
}
</script>

Whether Google actually follows these references is not clear (as far as I know, it’s undocumented)¹. It’s clear that their testing tool doesn’t show the data from referenced URIs, but that doesn’t have to mean much. At least their testing tool displays the URI (as "ID") in case one is provided.

If you want to provide a URL value for the video property, note that URL is not one of its expected values. While Schema.org still allows this (any property can have a text or URL value), it’s likely that some consumers will handle only expected values. It’s also perfectly fine to provide a VideoObject value if you only provide a url property. The fact that Google’s testing tool gives errors doesn’t mean that something’s wrong; it just means that Google won’t consider this video for their video-related rich results.

¹ But for the few rich result features Google offers, authors would typically not need to reference something from another page anyway, I guess. Referencing of URIs is typically done for other Semantic Web and Linked Data cases.

How to write Microdata or JSON-LD for ebook in SVG image format embedded/encoded in HTML5?

Syntax

If these are HTML5 documents, you have three options to provide structured data using Schema.org:

JSON-LD
Microdata
RDFa

While Microdata and RDFa define attributes that get added to your existing HTML elements, JSON-LD gets added in a separate script element.

Just because it represents a book (instead of a "normal" website) doesn’t change how JSON-LD/Microdata/RDFa can be added. Choose whatever syntax works best for you.

Vocabulary

For the whole book, you should use the Book type. EBook is not a type, but an enumeration value for the bookFormat property.

So you could have (example in JSON-LD):

<script type="application/ld+json">
{
  "@context":  "http://schema.org/",
  "@id": "http://example.com/foobar#book",
  "@type": "Book",
  "name": "Foobar",
  "bookFormat": {"@id": "http://schema.org/EBook"}
}
</script>

The URI in the first @id (http://example.com/foobar#book) would be the URI that represents the book. I added the #book fragment to differentiate between the actual book and the webpage that contains (or is about) the book (details). If you have a separate website for this book, it would make sense to use the website’s homepage URI (ideally with a fragment, like #book or something else).

Whenever you reference this book, you may use this URI instead of repeating the data on each page (e.g., for each page in isPartOf).

Does JSON-Ld Have to Be Embedded