Multiple contexts in JSON-LD - schema.org

How can I access two seperate vocabs in JSON-LD, can I use 2 #contexts?
e.g.
{
"#context": {
"#vocab": "http://schema.org/",
"first_name": "givenName",
"last_name": "familyName
}
"#context": {
"#vocab": "http://our_own_schema.org/",
"Time": "inputTime"
}
}

You can provide multiple #context. If they contain duplicated terms, the most recently defined term gets used. See examples 27 and 28. But if you want to mix vocabularies within the same object, this doesn’t work.
To allow mixing vocabularies within the same object, you could define all vocabularies in the #context at the top of the document. Each vocabulary can have a prefix, which allows you to use compact IRIs. One vocabulary can be the default one (without prefix).
With default vocabulary:
"#context":
[
"http://schema.org/",
{"oos": "http://our_own_schema.org/"}
],
The key name expands to http://schema.org/name,
the key oos:name expands to http://our_own_schema.org/name.
Without default vocabulary:
"#context":
{
"schema": "http://schema.org/",
"oos": "http://our_own_schema.org/"
},
The key name would be ignored,
the key schema:name expands to http://schema.org/name,
the key oos:name expands to http://our_own_schema.org/name.
Note: It’s always possible to use absolute IRIs as keys. You don’t have to define these in a context.

Related

Can JSON-LD "#id" be used to link to an item described on another web page?

I'm attempting to make correct and efficient use of schema.org json-ld recommandations for adding semantic to a web page.
I have a web page for unique organizations (http://example/organization1):
{
"#context": "http://schema.org/",
"#type": "Organization",
"#id" : "#ID_Organization1",
"name": "Organization1",
"url": "https://myorganization1.com
}
Can I reuse the information on that organization on another page without having to redeclare it ? (http://example/offers)
{
"#context": "https://schema.org/",
"#type": "Review",
"itemReviewed" : {
"#type" : "Organization",
"#id" : "http://example/organization1#ID_Organization1"
},
}
Check the following JSON-LD 1.1 documentation information:
3.3 Node Identifiers
To be able to externally reference nodes
in an RDF graph, it is important that nodes
have an identifier. IRIs are a fundamental concept of Linked Data, for
nodes to be truly linked, dereferencing the identifier should result
in a representation of that node. This may allow an application to
retrieve further information about a node. In JSON-LD, a node is identified using the #id keyword.
This probably means that there is no limit to using this element.

"Unspecified Type" in Structured Data Testing Tool

I have recently written json schema for my client's local business with multiple locations. I have run it through Google's Structured Data Testing Tool, but I have noticed that it is defined as "unspecified type" rather than LocalBusiness.
I am also trying to implement this schema onto my client's WordPress site via Google Tag Manager and it has not seemed to work (I am guessing that this is because it is unspecified type rather than LocalBusiness?).
You didn’t post your JSON-LD, but from the output of Google’s SDTT, I would guess that this is the reason:
You’re using graph instead of #graph. Without the #, it gets interpreted as a Schema.org property (which doesn’t exist), not as a way defined in JSON-LD to provide multiple top-level items.
So instead of something like
{
"#context": "http://schema.org",
"graph":
[
{
"#type": "Organization"
},
{
"#type": "LocalBusiness"
}
]
}
you need to have something like
{
"#context": "http://schema.org",
"#graph":
[
{
"#type": "Organization"
},
{
"#type": "LocalBusiness"
}
]
}

Schema.org Accommodation with price?

I'm attempting to add a schema for an Accommodation, but I can't seem to find a way to reference the 'offer' or 'price' to this schema. Im using JSON-LD to format this schema.
I have also tried room/hotelRoom as an alternative. I also tried using the additionalType value to allow me to use product based options such as offers, but this didn't work.
JSON-LD:
{
"#context": "http://schema.org",
"#type": "Accommodation",
"additionalType": "Product",
"name": "example",
"offers": {
"#type": "Offer",
"name": "1 Night",
"priceSpecification": {
"#type": "PriceSpecification",
"price": 1,
"minPrice": 1,
"maxPrice": 2,
"priceCurrency": "GBP"
}
}
}
Google Structured Data Testing Tool:
The property offers is not recognized by Google for an object of type Accommodation.
How am I meant to add a price to a specific accommodation/room in my schema?
Schema.org intends¹ that authors use MTEs² in this case. That, however, does of course not necessarily mean that all consumers fully support this (yet).
So instead of:
"#type": "Accommodation",
you would use:
"#type": ["Accommodation", "Product"],
(additionalType": "Product", is not needed anymore, so could be removed)
While Google’s Structured Data Testing Tool only displays one type (seems to be always the first value in the array), it reports no errors when using this.
¹ The accommodation documentation does not yet reflect this (the changes are currently part of the draft for the next version), and the topic gets discussed here:
Remove Accommodation from all of the Offer-related schema and use MTEs instead
Hotel examples and documentation must be updated for MTE pattern
² MTE: Multi-Typed Entity.

What is the length of the 'description'/'name' properties for the 'Product' type in Schema.org?

I am playing with Schema.org, creating extensions for Google Rich Snippets based on JSON-LD, using https://schema.org/Product.
{
"#context": "http://schema.org/",
"#type": "Product",
"name": "Executive Anvil",
"image": "http://www.example.com/anvil_executive.jpg",
"description": "Sleeker than ACME's Classic Anvil, the Executive Anvil is perfect for the business traveler looking for something to drop from a height.",
"mpn": "925872",
"brand": {
"#type": "Thing",
"name": "ACME"
}
}
But I do not understand which how long the value for description and name can be. Seems to me that this is a very important value.
The vocabulary Schema.org doesn’t restrict the length that Text values can have. Not for Product nor for any other type.
Consumers (like Google Search) might have their own rules/restrictions. These should, hopefully, be described in their documentation. For Google’s Products rich result, no restrictions are specified for name/description.
Google indicates between >50 and <5000

Using the HAL vocab with JSON-LD

I was wondering, is there a way to use the HAL concepts with JSON-LD?
I have the current jsonld document:
{
"#context": {
"hal": "http://stateless.co/hal#",
"schema": "http://schema.org",
"_links": {
"#id": "hal:link",
"#container": "#index"
}
},
"#type": ["schema:Person", "hal:Resource"],
"name": "Jon Snow",
"_links": {
"self": {
"href": "/users/123"
}
}
}
but I am not sure how to define that the href has a #type of #id, and so on...
Is there a way to define a HAL vocab based on RDF(S) and import it somehow in the #context of my jsonld documents, or should I do something else?
(I am trying to describe hyperlinks with various properties, like link relation, HTTP method, accepted media type, language, IRI template, input fields, etc... so the #id type is not enough for me to describe links.)
As Tomasz already suggested, you should really consider using Hydra as it does more or less what you want. The example you've included in your questions, would look somewhat like this using Hydra and JSON-LD:
{
"#context": {
"schema": "http://schema.org",
"ex": "http://example.com/myvocab#"
},
"#id": "/users/123",
"#type": [ "schema:Person", "hydra:Resource" ],
"name": "Jon Snow",
"ex:link": { "#id": "/another-resource" }
}
As there's no need for a "self" link (#id already specifies that explicitly), I've added another link, ex:link. Its link relation is consequently http://example.com/myvocab#link and its "href" is /another-resource. If you need to describe that link/property in more details, you can do so by creating a document which defines it in exactly the same manner as other things are described (as Tomasz also already explained):
{
"#context": {
"ex": "http://example.com/myvocab#",
"hydra": "http://www.w3.org/ns/hydra#"
},
"#id": "ex:link",
"#type": "hydra:Link",
"hydra:title": "My new link relation",
"hydra:supportedOperation": [
{
"#type": "hydra:Operation",
"hydra:method": "POST",
"hydra:expects": ....
}
]
}
Regarding your comment
Btw. I am more or less familiar with the Hydra vocab, but I don't like
the idea to map the resources to real classes and objects on a server
side language and automatically transform the operation parameters
into those objects. Maybe it is possible to use the Hydra vocab in
another way, but I don't have the time to experiment with that.
Hydra is really just a vocabulary. It is up to you to decide how to use it. I think you are talking about the HydraBundle above. That's just one way to use it. It is just a proof of concept to show that it is easily possible. So please don't get confused by that.
I would like to invite you to join the Hydra W3C Community Group. We can then discuss this in more detail on our mailing list.
Disclaimer: I'm the creator of Hydra and the chair of the Hydra W3C Community Group.
I think you could be interested in Hydra. Have you tried that?
It's a vocabulary for describing Hypermedia links and operations. Here's how it could work for a simple parent link
{
"#context": {
"schema": "http://schema.org",
"parent": {
"#id": "/vocab#parent"
"#type": "#id"
}
},
"#id": "/users/123",
"#type": "schema:Person",
"name": "Jon Snow",
"parent": "/users/Ned_Stark"
}
Note that you don't need to include any data outside your domain in the representation. Instead you describe what the parent predicate means
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "/vocab#parent",
"#type": "hydra:Link"
}
You can also describe operations (HTTP methods, ranges, domains, etc.) and properties for classes. Also the operations can be included directly in the representation or attached to the classes and proeprties.