I have a client who operates two different blogs on different domains. One domain/blog is b2c focused, while the other is b2b focused. Having it on two domains allows them to specifically target each separate audience and not bombard their b2c crowd with information that's irrelevant to them.
What we would like to achieve is to have both blogs surface for branded related search terms. So I'm wondering if schema 'sameas' would be appropriate in communicating to Google that both domains are of the same ownership and property.
Secondly, the business is also known to the public by two different names. One being a short-hand form and the other being the full LLC name. Both of which are searched frequently. So what I have is as follows:
<script type="application/ld+json">
{
"#context" : "http://schema.org",
"#type" : "Organization",
"name" : "Short Hand",
"alternateName" : "Full llc",
"url" : "http://b2c.com",
"sameAs" : [
"http://b2b.com"
]
}
</script>
Just want to confirm that I understand this schema and I'm implementing it properly. Is this correct? Thanks.
Related
I'm building a REST API powered SPA application and I'm trying to decide on the best way to deliver "global options" via the API. By global options I mean an assortment of random fields that relate to the application as a whole rather than being associated with one specific model, for example brand logos and contact details that need to be accessible from multiple locations within the app.
Something like Wordpress would store these in an options table and access them via a php function using the option name, however since this is a REST API I'm not sure how I would go about accessing/updating multiple options without making lots of requests for each one.
I know a lot of projects just use a json file to store this data, but it specifcally needs to be editable via a CMS and served via the API. The following are two methods that have come to mind, but none of them feel like complete solutions:
1: An options table with one generic endpoint that takes a query string specifying which fields you want to access. This works for getting data, however updating data seems to get a bit messy and the only way I can think to do this is by sending an object of key/values pairs to bulk create or update the options:
GET: example.com/api/options?pick=logo,contact_phone,contact_email
POST: example.com/api/options
{
contact_email: "info#example.com",
contact_address: "123 Test St"
}
PUT: example.com/api/options
{
contact_email: "info#example.com",
contact_address: "123 Test St"
}
2: Breaking fields into groups and storing them as a json field in a "pages" table, this solves the creating and updating issues but breaks down when you have fields are used in multiple locations, and they aren't really pages so it's not very REST like.
GET: example.com/api/pages/contact
POST: example.com/api/pages
{
name: "contact",
values: {
email: "info#example.com",
address: "123 Test St",
}
}
PUT: example.com/api/pages/contact
{
values: {
email: "info#example.com",
address: "123 Test St",
}
}
I also need to take into account the issue of access permissions, for example the logo field would be accessible to the public, but the user support contact number would only be accessible to logged in users. With the first example you could have an extra permission column for each option, but this wouldn't work for the second option.
I've been googling but have failed to find any good information about this topic as REST schemas/documention generally only deal with concreate entities, so any insight into how this is achieved in real world applciations would be great!
Cheers,
Cam
I got this link but didn't understand well. Saw:
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"url": "http://website.com",
"name": "wbs",
"description": "Web Studio"
}
</script>
in a source code.
How a code snippet like above in my website header help me or my site?
In your example, the script element is used as data block, which contains JSON-LD (type="application/ld+json").
JSON-LD is a RDF serialization. It allows you to publish Linked Data (or structured data) using JSON. In your example, the vocabulary Schema.org is used ("#context": "http://schema.org").
This structured data can be used by any interested consumer. Prominent consumers are the search engines Bing, Google, Yahoo, and Yandex, which support structured data that uses the vocabulary Schema.org. One use case they have is displaying more details in their result snippets.
Your example probably doesn’t lead to such an enhanced snippet. You have to check the search engine’s documentation if you want to know what features they offer and which structured data you have to provide for these. For example, Google uses the WebSite type (that’s used in your example) for their Sitelinks Search Box, but you would have to add a potentialAction in addition (for the search function).
It gives Google and other crawlers structured data about a website. This is used for rich snippets and knowledge graph panels among others. Have a look at this site for more information: https://developers.google.com/search/docs/guides/intro-structured-data
That's one way to include structured data in your site which helps any kind of users/crawlers use the information on the site in an efficient way. The most popular example is Google news cards:
This kind of card data are actually coming from structured data.
Other ways to include structured data is through Microdata
And the time of asking this question, I have no idea about these. Now I worked on structured data for some publishers.
The snippet you got is a script containing JSON-LD data format, a method of encoding Linked Data using JSON. Schema.org vocabulary is used to mark up web contents so that they can be understood by majors search engines (Google, Microsoft, Yandex and Yahoo!). Search engines use this information to display to display relevant .contents to users. For instance, you a website with a well-known term as it’s brand name e.g. Coder. Search engines will interpret it as someone who writes code for softwares. To help search engines interpret this better, you need to provide the data using Schema.org vocabulary.
e.g.
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"url": "https://coder.com",
"name": “Coder”,
"description": “Platform to learn code”
}
</script>
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"url": "http://website.com",
"name": "wbs",
"description": "Web Studio"
}
</script>
The snippet above is a JSON-LD based Structured Data Island (or Block) embedded in HTML that provides data to User Agents (Software Apps) for additional processing. This data can take the form of Metadata that informs said User Agents about the nature of the host document.
For instance, you can inform a User Agent such as Google's Crawler about the identity of a person associated with a document by embedding the following structured data island:
## JSON-LD Start ##
{
"#context": "https://schema.org",
"#type": "Person",
"#id": "https://stackexchange.com/users/74272/kingsley-uyi-idehen#me",
"mainEntityOfPage": "https://stackexchange.com/users/74272/kingsley-uyi-idehen",
"sameAs": "https://stackexchange.com/users/74272/kingsley-uyi-idehen",
"name": "Kingsley Uyi Idehen",
"description": "#kidehen Identified at Web, relatively"
}
## JSON-LD End ##
This is possible because the semantics that underly the schema:sameAs property deem it to be uniquely identifying.
You can also add a browser extension (e.g., our Structured Data Sniffer) to your existing browser(s) that understands the power of structured data islands deployed using , producing what's depicted in the attached screenshot.
I wrote this JavaScript code for users to write your brand name on Google.
The search form will be displayed to users.
Users only need to type in your brand name to display this search and it is most commonly used on the homepage.
To use this code copy the JavaScript and paste it at the bottom of the last line of the main content, and don't worry the JavaScript code will not be displayed to users and will only appear in Google results.
<script type="application/Id+json"> {
"#context": "schema.org",
"#type": "WebSite", "url": "coolernew.com", "potentialAction": {
"#type": "SearchAction", "target": "query.example.com/search?q={search_term_string}", "query-input": "required name=search_term_string"
}
} </script>
I have a handful of WordPress websites that use The Events Calendar for displaying events that are open to the public.
I notice if I type a cities name and then the word event, that our website is not being pulled in to the special section that appear. Google uses its Knowledge Graph. I was looking through the source code and noticed that our sites uses JSON-LD, generated from the information used for the event, one of the methods Google talks about using, but don’t understand why our site information isn’t being shown.
These sites have been up a year and get 3k visits a month so they're being indexed fairly regularly.
I was looking through the event properties JSON-LD, and I noticed the entire event address (street, city, state zip) gets put inside the name property of the Place or Postal array (Heres a screenshot of my sites schema). When I look up other events that are pulled into Google, they list the those attributes in the address properties (Screenshot of other site’s schema).
I think because the address is put into the name property instead of the address property, that Google might not be showing the events. Has anybody else seen this happen with their sites? Or is something else wrong with the sites we set up?
Right now your events are marked up using the Google example, but I believe this is wrong:
https://developers.google.com/structured-data/rich-snippets/events
"location" : {
"#type" : "Place",
"sameAs" : "http://www.hi-dive.com",
"name" : "The Hi-Dive",
"address" : "7 S. Broadway, Denver, CO 80209"
}
2019 edit: The markup and URL above have since changed and match what is expected from the testing tool.
In order for your sites structured data to match that other event you have a screen shot of, you will need to adjust your JSON-LD to the way it's presented on schema.org, which uses PostalAddress and narrows down a little bit more:
https://schema.org/location (and https://schema.org/PostalAddress) - Click the JSON-LD example tabs
"location": {
"#type": "Place",
"name": "Withworth Institute",
"address": {
"#type": "PostalAddress",
"addressLocality": "Seattle",
"addressRegion": "WA",
"postalCode": "98052",
"streetAddress": "20341 Whitworth Institute 405 N. Whitworth"
},
"url": "wells-fargo-center.html"
}
I can't say for certain if this is the primary reason for your issue but I do think you should follow the schema.org approach either way. Even the Structured Data Tool per your screenshots seems to indicate that it's looking for postalAddress even though Google doesn't use that in the example.. perhaps that article is outdated.
I can confirm that a migration to JSON-LD from inline RDFa style schema, which validates 100% using their new rich snippet validator tool no longer shows Review stars in search results. They've also taken away the ability to see stars validate using old style RDFa schema validation.
This could be an issue with the search team not talking to the developers responsible for the structured data and schema tools, rolling out disjointed feature upgrades. Their recommended use of JSON-LD will likely have a negative impact on display in search in the near term if you'd like to see additional meta data populate in search results pages.
If meta data in search results is a firm requirement you could roll off your JSON-LD module and use a module with the older RDFa or microdata implementation inline in your HTML. Hopefully this will be remedied soon.
Let's assume that I have a resource called group with the following representation:
{
"id": 1,
"name": "Superheroes"
"_links": {
"self": {
"href": "http://my.api.com/groups/1"
}
}
}
Now let's say I want to create a new person instance by POSTing to /persons/1. Which of the following should I use for the request body:
Using ID
{
"name": "Batman",
"groupId": 1
}
Using link
{
"name": "Batman",
"group": "http://my.api.com/groups/1"
}
With the first method I access the id directly either to look up the related resource or eventually store the id in the database, when I persist the person instance. But with the other method, I either have to extract the id from the URI or, follow the link to load the related resource, and then find out its id. I really don't want to store the URI in the database.
With the latter option, seeing that the server controls the structure of the URI, is it fine for me to parse the id out of the link? Following the link back to the server itself seems odd, seeing that at this point we already have access to the information directly (we just need the id).
So to sum up, which of these options is best?
Use the id directly.
Use the link, but parse out the id.
Use the link, but access the link to get the resource instance, and then get the id.
TL;DR: Use simple ids.
More detailed explanation:
A straightforward approach is to create a person by POSTing to /groups/1/persons with a payload {"name": "Batman"}.
However, while such approach works for simple cases, the situation gets complicated if there are 2 resources that need to be referenced. Let's assume that a person also needs to belong to exactly one company:
GET /persons/1
{
"name": "Batman",
"group": 1, // Superheros, available at /groups/1
"company": 5 // Wayne Enterprises, available at /companies/5
}
Since there is no relationship between companies and groups, it is not semantically correct to create a person via POSTing to /groups/1/companies/5/persons or to /companies/5/groups/1/persons.
So let's assume you want to create a person with a request looking like this:
POST /persons
{
"name": "Batman"
"group": ???, // <--- What to put here?
"company": ??? // <--- What to put here?
}
Which brings us to the answer to your question:
Ease of use. Your API should be primarily designed for the ease of use. This is especially true, if you design a public API. Therefore, Option 2 (Use the link, but parse out the id) is out, since it imposes additional work for clients of your API.
Constructing search queries. If you want to be able to query persons which belong to the company 10 and the group 42, simple ids lead to more readable and less error-prone urls. Which of the following do you consider more readable?
URL with a simple id:
GET /groups/42?company=10
or URL with a url-encoded link:
GET /groups/42?company=http%3A%2F%2Fmy.api.com%2Fcompanies%2F10
I wouldn't underestimate the point of readability. How many times do you need to debug your API in various curls, logs, postmans, etc.
Development Links need to be parsed in the backend, while simple ids can be used directly. It's not about performance, but rather about additional work/tests you have to put in.
Endpoint maintenance. Imagine that your API endpoint evolves. You decide one day to switch to https or to include versioning in the url. This might break API clients, if they for some reason rely on structure of the links. Also, you might want to checkout if link parsing on your backend is done properly.
Argumentum ab auctoritate I know this is not a proper argument, but if you checkout APIs of large players, e.g. Twitter, Github or Stripe, they all use simple ids.
HATEOAS. One common argument in favour of links is that it is aligned with HATEOAS. However, as far as I know, this relates to additional links in API responses rather than using links in payloads of POST requests.
All in all, I would go for simple ids, since I haven't yet heard a compelling argument favouring links, which would beat the aforementioned.
You are missing two important things here.
You need a standard way to describe forms in the response, in this case your POST form.
The information about the group ids / uris, or how to get them has to be described in the form in a standard way.
For example a HTML FORM with a SELECT INPUT would be RESTful. The closest thing we got in json to do the same is json-ld and hydra. But if you are obsessed with hal, then use hyperagent forms or something like that. It will never be a standard, but if compatibility is not an issue, then it is good enough.
To answer your question, you should use the id, because the server knows how to interpret it. The client needs the resource identifiers, the server needs it only in the uri part of the request, not in the body.
From my experience, it is always best to go with the simplest solution for making requests.
The process of generating a new url and parsing it seems excessive to get a resource, whereas sending the id of the item you want seems much simpler.
Thus, I would send a request in the form:
{
"name": "Batman",
"group": 1
}
I am creating a desktop application using node-webkit.
The purpose of creating the application is to add documents and that anyone can comment on the document. The document will be split into paragraphs and people can comment on the paragraphs. Each of the paragraphs will be considered as different sections. I would like to link each section (or paragraph) with the comments using JSON-LD.
I am new to JSON-LD and I would like to know how it can be used.
In a document (an HTML document, anyway), sections (or any element) can be identified using the #id attribute, which typically becomes a fragment identifier for the document. For instance, http://www.w3.org/TR/json-ld/#abstract is a URL with the "abstract" fragment identifier, if you look at the html source, you'll see the following:
<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:chapter"><h2 aria-level="1" role="heading" id="h2_abstract">Abstract</h2>
<p>JSON is a useful data serialization and messaging format.
This specification defines JSON-LD, a JSON-based format to serialize
Linked Data. The syntax is designed to easily integrate into deployed
systems that already use JSON, and provides a smooth upgrade path from
JSON to JSON-LD.
It is primarily intended to be a way to use Linked Data in Web-based
programming environments, to build interoperable Web services, and to
store Linked Data in JSON-based storage engines.</p>
</section>
(note that some of this is automatically generated, so there is other non-relevant boiler plate as well).
This provides you one mechanism of describing the structure of a document using JSON-LD:
{
"#id": "http://www.w3.org/TR/json-ld",
"#type": "bibo:Document",
"bibo:chapter": [{
"#id": "#abstract"
}, {
"#id": "#sotd"
}, {
"#id": "#references"
}],
}
Note, in this case, the JSON-LD is defined to have the same URI (URL) of the HTML document, so the "#abstract" really expands to http://www.w3.org/TR/json-ld#abstract, this providing you a way to reference that section, and an identifier for the section. Much more is possible.
In fact, many W3C specifications are marked up in RDFa, as both RDFa and JSON-LD are RDF formats, you can actually turn this document into JSON-LD with an appropriate too, such as the RDF distiller I maintain. For example, try the following in your browser: http://rdf.greggkellogg.net/distiller?fmt=jsonld&in_fmt=rdfa&uri=http://www.w3.org/TR/json-ld/#abstract.