I'm describing a site for distance education with schema.org and JSON. Any pages are with this:
<body itemscope itemtype="http://schema.org/WebPage">
but I have many pages for every course - German course, Economics course, Hairdressing course etc. (Product pages) and I was described them with
<body itemscope itemtype="http://schema.org/ItemPage">
How is better to describe them - with WebPage or with ItemPage ?
In schema.org the description for ItemPage is "A page devoted to a single item, such as a particular product or hotel." I am not sure what is better. Please help.
Thanks
If the page is about a single course, then yes, you may use ItemPage.
As a general rule, always go with the most specific type. So if you have a WebPage, check its "More specific Types"; if one of the types applies to your case, select it; otherwise, keep WebPage.
Of course this type only represents the web page about your course, not the course itself. So you’d probably want to use mainEntity to reference an EducationEvent (or whichever type applies).
Related
After reading thousand of posts, questions, blog articles and opinions, I'm still a bit confused about how to markup a web page with microdata. If the main purpose of microdata is to help search engine to better understand the content of a web page (and web page is assumed implicitly), is it correct to start with itemtype Webpage in the body element, and then continue to markup the rest of nested elements defining which is the main entity, or is it better to start with an itemtype that is ideally the main topic of the web page and associate properties at the top level, or is better to have different itemtype at the top level (i.e. webpage, blog post and main topic of the page)?
An example will explain better my question: if I have to markup a webpage that contains a blog post about a specific topic (let's say about wireless technology), what should be the item at the top level? Should be webpage, blogposting, or wireless technology?
The more the better (with exceptions)
When it comes to structured data, the guideline should be, in the typical case: the more the better. If you provide more structured data (i.e., you make things explicit instead of keeping them implicit), the chance is higher that a consumer finds something it can make use of.
Reasons not to follow this guideline might include:
You know exactly which consumers you want to support, and what they look for, and you don’t care about other (e.g., unknown or new) consumers.
You know that a consumer is bugged in a way that it can’t cope with certain structures.
You need to save as many characters as possible (bandwith/performance).
It’s too complex/expensive to provide additional structured data.
The structured data is most likely useless to any conceivable consumer.
…
What WebPage offers
So unless you have a reason not to, it’s probably a good idea to provide the WebPage type … if you can provide possibly interesting data. For example:
It allows you to provide different URIs for the page and the thing(s) on the page, or what the page represents, like a person, a building, etc. (see why this can be useful and a slightly more technical answer with details).
hasPart allows you to connect items which might otherwise be top-level items, for which it wouldn’t necessarily be clear in which relation they are.
isPartOf allows you to make this WebPage part of something else (e.g., of the website if you provide a WebSite item, or of a CollectionPage).
You have breadcrumbs on the page: use breadcrumb to make clear that they represent the breadcrumbs for this page.
You provide accessibility information: use accessibilityAPI, accessibilityControl, accessibilityFeature, accessibilityHazard
The author/contributor/copyrightHolder/editor/funder/etc. of the page is different from the author/… of e.g. the page’s main content.
The page has a different license than some of the parts included in the page.
You provide actions that can be done on/with the page: use potentialAction.
…
Of course it also allows you to use mainEntity, but if this were the only thing you need the WebPage item for, you could as well use the inverse property mainEntityOfPage.
More specific WebPage types
And the same is true for the more specific types, which give additional signals:
AboutPage if it’s a page about e.g. the site, you, or your organization.
CheckoutPage if it’s the checkout page in a web shop.
CollectionPage if it’s a page about multiple things (e.g., a pagination page listing blog posts, a gallery, a product category, …).
ContactPage if it’s the contact page.
ItemPage if it’s about a single thing (e.g., a blog posting, a photograph, …).
ProfilePage e.g. for user profiles.
QAPage if it’s … well, this very page.
SearchResultsPage for the result pages of your search function.
…
Your example
Your three cases are:
<!-- A - only the topic -->
<div itemscope itemtype="http://schema.org/Thing">
<span itemprop="name">wireless technology</span>
</div>
<!-- B - the blog post + the topic -->
<div itemscope itemtype="http://schema.org/BlogPosting">
<div itemprop="about" itemscope itemtype="http://schema.org/Thing">
<span itemprop="name">wireless technology</span>
</div>
</div>
<!-- C - the web page + the blog post + the topic -->
<div itemscope itemtype="http://schema.org/ItemPage">
<div itemprop="mainEntity" itemscope itemtype="http://schema.org/BlogPosting">
<div itemprop="about" itemscope itemtype="http://schema.org/Thing">
<span itemprop="name">wireless technology</span>
</div>
</div>
</div>
A conveys: there is something with the name "wireless technology".
B conveys: there is a blog post about "wireless technology".
C conveys: there is a web page that contains a single blog post (as main content for that page) about "wireless technology".
While I wouldn’t recommend to use A, using B is perfectly fine and probably sufficient for most use cases. While C already provides more details than B (namely that the page is for a single thing, and that this thing is the blog post, and not some other item that might also be on the page), it’s probably not needed for such a simple case. But this changes as soon as you can provide more data, in which case I’d go with C.
My HTML content has reviews data and so I am wrapping it in a div which has itemtype and itemscope attributes defined, telling the browser it uses HTML5 Microdata. But how should I handle the scenario when there are no reviews (for example a new product in my store doesn't have any reviews submitted for it yet).
Right now I am doing something like this...
<div itemscope itemtype="http://data-vocabulary.org/Review-aggregate">
<meta itemprop="count" content="0 Reviews">
<meta itemprop="rating" content="0.0">
There are no reviews for this item.
</div>
A simple message for the user saying there are no reviews, and a couple of meta tags telling the Bot the same.
But Google's Structured Data Testing Tool complains for this saying....
"Failed to normalize the rating value.
Your rating value was out of the default range, you must provide best and worst values."
And if I leave rating out altogether then it complains saying rating is "missing and required".
How can I make it happy in the case when there are no reviews for my content?
The Review-aggregate type represents "a review of a business, product or organization". You don’t have a review. So you should not use this type at all.
<div>
There are no reviews for this item.
</div>
By the way, unless you have a specific reason for using Data-Vocabulary.org, you might want to use Schema.org instead (or in addition). Data-Vocabulary.org is no longer maintained. The advice stays the same: don’t use a type if you don’t have the thing this type represents.
Microdata with Schema.org already better describes any element than HTML5, it seems redundant? For example:
<nav itemscope itemtype="http://schema.org/SiteNavigationElement">
<!-- might as well just be... -->
<div itemscope itemtype="http://schema.org/SiteNavigationElement">
and
<article itemscope itemtype="http://schema.org/NewsArticle">
<!-- might as well just be... -->
<div itemscope itemtype="http://schema.org/NewsArticle">
Some elements create an "outline" for the webpage, but aside from that what's the point? Why not just use divs and forget about the semantic tags, and just use Microdata and Schema.org?
The schema.org definitions are specifically for applications such as search engines (From What is schema.org?):
This site provides a collection of schemas, i.e., html tags, that
webmasters can use to markup their pages in ways recognized by major
search providers. Search engines including Bing, Google, Yahoo! and
Yandex rely on this markup to improve the display of search results,
making it easier for people to find the right web pages.
Your mark-up needs to be understood by browsers and screen-readers as well as search engines (from the schema.org Getting started page):
Usually, HTML tags tell the browser how to display the information
included in the tag. For example, <h1>Avatar</h1> tells the browser to
display the text string "Avatar" in a heading 1 format. However, the
HTML tag doesn't give any information about what that text string
means—"Avatar" could refer to the hugely successful 3D movie, or it
could refer to a type of profile picture—and this can make it more
difficult for search engines to intelligently display relevant content
to a user.
So microdata allows you to add additional semantic meaning to your mark-up (using definitions provided by schema.org) which can be ignored by applications which don't need it, such as browsers, and read by applications which do, such as search engines.
Microdata is not a replacement for using the appropriate semantic-HTML tags where available, it should be used to augment that information. So the simple reason to use nav and article tags along with the microdata is that these tags have meaning to browsers and screen-readers, while the microdata does not.
Actually, your examples are fairly simplistic. I would suggest you have a look at some of the examples on the schema.org getting started page to see how microdata can be used more meaningfully.
To see microdata being used in practice, try googling yourself and inspecting the results. If I search for myself, the first three results (LinkedIn, github and my portfolio page) all display information marked up using microdata which google can pull from the pages and present to the user to help provide more meaningful search results.
The vast majority of terms that we have in schema.org have no overlap with HTML terminology, since they represent kinds of real world thing such as places, processes, products etc.
The problem area highlighted here is the small set of terms around http://schema.org/WebPageElement . I am not aware that any current search engine features make specific use of these, and I would suggest that any publishers who do see value in their use should also employ the corresponding pure HTML markup as well.
So recently am reading a book called Adaptive Webdesign and I came across something called an hcard, hcalendar and I went to it's respective documentation page. Now the question is am not understanding how this works? It is used to represent people..and the markup goes like this
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
Now I know these classes have meanings like url indicates that a given link takes the user to a webpage and fn signifies formatted name so on...
So does these classes point the search engines that the content is a hCard or it render's differently etc..Can someone explain me how this works, whats the benefits to do so, and does this have importance from SEO point of view and are these classes predefined?
Edit: So are these classes reserved? What if I use them for other elements? And is there any javvascript which I can call onclick of a button to save a vcard on computer/user device?
This concept allows machines the get detailed informations about content. It's quite simple, you know what a given name is. Machines does not... :)
So you need a way to tell a machine what kind of data your html contains.
For example: You could enrich your data like the example below and allow, maybe an Adressbook-Application, to get detailed informations about which fields should be filled.
<div class="vcard">
<a class="url fn" href="http://tantek.com/">
<span class="family-name">Tantek</span>
<span class="given-name">Çelik</span>
</a>
</div>
This snippet allows the Adressbook-App. to find the given name easily and set it to the correct field. Order doesn't matter here.
Test your "Rich Snippets": http://www.google.com/webmasters/tools/richsnippets
If you haven't declared that you're using the hCard syntax (by using the vcard class), then you're free to use whatever class names you'd like. Even if you did start using the hCard microformat, no styles will be applied implicitly, as microformats are not related to display style.
The purpose of using microformats is to open an interface for exposing metadata. By providing the data in a standardized microformat, anyone parsing your website can use the microformat to find relevant information.
Search engines in particular benefit from this as it allows them to provide more information about a particular resource on their results page.
vCard is a standard for an electronic business card. hCard takes these labels and uses them as class names around data in HTML.Every hCard starts inside a block that has class="vcard".
Some of these types have subproperties. For example, the 'tel' value contains 'type' and 'value'. This way you can specify separate home and business phone numbers. The 'adr' type has a lot of subproperties (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value).
<div class="vcard">
<div class="fn">xxxxx</div>
<div class="adr">
<span class="locality">yyyy</span>,
<span class="country-name">zzzzz</span>
</div>
</div>
The class names don't have to mean anything within your page. However, you can always take advantage of them to style your contact information. You could also style them in your browser's User Style Sheet, so that you can find them while you surf the web. (Original source)
Regarding the SEO aspects, Please checkout this article Tips for Local Search Engine Optimization for Your Site
I don't know exactly of hcard and hcalendar, but for instance, look up a Stack Overflow question on Google, you'll see that the time when it was posted appears next to the content, for many sites it also displays the name of the author.
In other words, Google will use these microformats to enhance the search experience, by providing meta-data for the search as it was parsed from the page.
You help Google, they help you.
I'd recommend you to use http://schema.org/ for microformats. Google officially recommends using it, and it is also fully supported by Bing and many other search engines. When you use schema.org microformats, search engine crawlers will extract data entities from your markup and will display them in search results in corresponding manner.
So yes, there are benefits of using microformats. By using them you can improve behavior of search engine crawlers, your content will be properly indexed and what is more important, it will be properly categorized, so it will appear in customized searches.
One of the sites I develop has lots of information linked between each other; we have companies, we have products for those companies. The company page links to the page listing the products for that company, and vice versa.
From the HTML spec:
CITE:
Contains a citation or a reference to other sources.
Does this imply that I could (semantically) use a <cite> for a company link? What about on the company page to a product?
If not, could someone tell me what might be the "correct" semantic tag for this?
If you're just linking to other pages then semantically you should just use <a href=...>. If you're quoting a small piece of information, like the information from the HTML spec in your question, and providing a link to the original source, you might use <cite>. Think of it as a citation in a book or research paper.
I'm not sure that cite is intended to mark up links - you may be looking at something akin to a more professional (less inter-personal) XFN using the rel attribute of the link.
Cite is more for marking up titles of articles or other created work.
XFN is specifically for marking up the relationship you (or your company) have with the person or company you are linking to. What I'm not sure of is what xfn values there are (if any) for company links.
http://reference.sitepoint.com/html/xfn
What you might consider is in what detail will the information be used? Semantic markup, although a noble direction to head in, is not yet utilised to it's full extent when looking at (by a human) or parsing (by a program) a resource.