Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Just wondering whether you guys out there are favouring the OpenGraph protocol following markup like:
<meta property="og:title" content="The Rock" />
<meta property="og:type" content="movie" />
<meta property="og:url" content="http://www.imdb.com/title/tt0117500/" />
Or the Schema.org protocol with
<div itemscope itemtype="http://schema.org/Product">
<span itemprop="name">Kenmore White 17" Microwave</span>
<img src="kenmore-microwave-17in.jpg" alt='Kenmore 17" Microwave' />
<div itemprop="aggregateRating"
itemscope itemprop="http://schema.org/AggregateRating">
Which one should I integrate as I think only 1 is necessary ? [actually can you only integrate one or ?]
Frankly, IMHO - I think OpenGraph is "less intrusive" to the total codebase - as it's easier to implement Partial Views [using ASP.NET MVC] whereas the Schema.org protocol requires [at least in my opinion] disruptive HTML add-ins across your code ?
Edit: Seems I ended up integrating both - not sure whether this is allowed but the documentation on Schema.org is unclear. Notably, this link doesn't provide much info
Q: How does schema.org relate to Facebook Open Graph?
Facebook Open Graph serves its purpose well, but it
doesn't provide the detailed
information search engines need to
improve the user experience. A single
web page may have many components, and
it may talk about more than one thing.
If search engines understand the
various components of a page, we can
improve our presentation of the data.
Even if you mark up your content using
the Facebook Open Graph protocol,
schema.org provides a mechanism for
providing more detail about particular
entities on the page. For example, a
page about a band could include any or
all of the following:
A list of albums
A price for each album
A list of songs for each album, along with a link to hear samples of each song
A list of upcoming shows Bios of the band members
So I assume that they are compatible together.
So, to start with a couple of cliche's and mangled metaphors - we're talking apples and oranges a bit comparing OG and Schema.org, and when it comes to this metadata it's horses for courses.
The right answer depends on your intent, in adding metadata to your page. What is it that you're hoping to gain? What is the win for you here? The different forms of metadata are for slightly different purposes.
Google has made it clear that it's moving away from a focus on microformats and onto a focus on Schema.org in order to build rich-data results for search. If you want to optimize for Google, Bing and other search engines add the Schema.org markup. It's the direction HTML5 has stepped in.
Facebook OG markup is to be added if what you want is to benefit from turning your content into a social object and enable its multi-point connectivity to the social graph that is the Facebook universe.
In my experience most people are looking to gain from both approaches - do as well as they can in search rankings and increase reach and distribution through social channels. So, IMHO, it's probably best to be as thorough as possible adding the Schema.org markup where it fits your content and use Open Graph metadata. They do slightly different, but complementary things.
We are talking about two separate concepts here: syntax and vocabulary.
The Open Graph Protocol and Schema.org are vocabularies. Other vocabularies are, for example, Dublin Core, FOAF, and SIOC.
These vocabularies are typically not coupled to a specific syntax. If you want to describe your content in HTML documents with such a vocabulary, you could use the syntaxes RDFa and/or Microdata.
Which one should I integrate as I think only 1 is necessary ? [actually can you only integrate one or ?]
Your first example uses Open Graph Protocol (= vocabulary) with RDFa (= syntax). Your second example uses Schema.org (= vocabulary) with Microdata (= syntax).
You can mix them up as you like. (You could use both vocabularies with both syntaxes on the same page. You could use both vocabularies with only one syntax. You could use only one vocabulary with both syntaxes, or with only one syntax. …). It totally depends on your specific use case.
What do you want to achieve? If you are interested in a specific 3rd party parsing your content, you should check their documentation. They typically support only certain vocabularies with certain syntaxes.
But if you want to mark up your content with semantic metadata without having a specific use case in mind, you could stick to one syntax and use whichever vocabularies are appropriate for your content. Personally, I’d choose RDFa (Lite). It is based on RDF, which works with other formats than HTML, too. It is a W3C Recommendation (Microdata is not). And most vocabularies you’ll find are defined in RDF(S). See my answer about the future of RDFa and Microdata.
All depends if you're trying to markup your website for a social world (facebook) or search engines. Both are recommended but if you only have time for one then prioritize the company's marketing focus. OGP is huge for facebook, but does not have an ounce of use in SEO. Seo is completely reliant on micro-data and is the way for proper html5 creation.
HTML5Doctor on Microdata
http://html5doctor.com/microdata/
Google talking about markup:
http://www.google.com/support/webmasters/bin/answer.py?answer=1211158
Bing talking about markup:
http://onlinehelp.microsoft.com/en-us/bing/hh207238.aspx
Update
For anyone finding this answer, a lot has changed since I first posted it.
Schema.org is widely used by all major search engines and then some but the markup is now preferred to JSON-LD. Great article from SEO Skeptic outlining the change made by Google.
Google Structured Data provides documentation in JSON-LD and is greatly encouraged although RDFa and microdata is still partial supported.
JSON-LD should be used in conjunction with any social channels you are trying to target OGP for Facebook, Twitter Cards for Twitter, etc
They can both be used safely together. Currently the two efforts use different syntaxes to encode data in HTML (W3C RDFa or Microdata), but there are active discussions at W3C towards eventual convergence of those designs. Or greater compatibility, at least. Whether there will also be convergence at the vocabulary level between Schema.org and OGP, or services that consume both, remains to be seen. But in the meantime they both add value and can be safely combined.
Google does favor schema, and open graph is better for web content that is related to social media. Your sample code looks good, but don't forget to include the prefix
<html prefix="og: http://ogp.me/ns#">
in the head of each page that has ogp.
You can check to make sure the ogp or schema works by using the rich snippet testing tool
http://www.google.com/webmasters/tools/richsnippets
In the case of Schema, you can check by using the SDTT: Structured Data Testing Tool
https://search.google.com/structured-data/testing-tool
Why not use json-ld for markup? I'm thinking of implementing json-ld based schema.org markup. That way it'll not be intrusive. My ghost blog uses it. Don't know if it's well supported by search engines yet. But all examples on schema.org now includes implementation for json-ld.
see here
http://schema.org/WebPage
And all my apps use twitter cards, fb opengraph tags and microformats tags like rel and structured schema.org metadata. And I find implementing schema.org metadata most instrusive. So replacing this last bit with json-ld and keeping code clean is nice. Too many tags and it's recommended to keep your html small ;)
RDFa og serves as uniform way to recognize content better by REST for consideration when embedding within containers not predicted at the time of creation. If the container is predetermined as search results, then schema.org microdata is well-understood by search bots. With og presentation is responsibility of container publisher & such quality freedom might improvise search ranking, while schema.org will improvise search result comprehensibility in the context of content creator's intent. The vocabularies usually are ignored when used with the competing semantic markup technique so best to use microdata with schema.org only and og with RDFa only. Both microdata and RDFa can coexist in same document.
rdfa(opengraph) and microdata(schema) cannot be used on same html page
"3) We’ll continue to support our existing rich snippets markup formats.
If you’ve already done markup on your pages using microformats or RDFa, we’ll continue to support it. One caveat to watch out for: while it’s OK to use the new schema.org markup or continue to use existing microformats or RDFa markup, you should avoid mixing the formats together on the same web page, as this can confuse our parsers."
SRC: http://googlewebmastercentral.blogspot.in/2011/06/introducing-schemaorg-search-engines.html
Related
My webpage is devoted to generic places, where users vote for them, and I'm trying to make Google to show rich snippets with star-rating votes for such webpages.
I've been reading the Schema.org documentation, and found two types which can help me:
Place
Article
However, I've been browsing the webpage of Google dealing with review snippets, and they claim that publishers can "supply ratings for the following content" types:
Books
Local businesses
Movies
Music
Products
Recipes
Are such categories the only accepted ones to show review snippets?
I see some webpages using Article or just the hReview-aggregate Microformat without mentioning the type, to show review snippets.
Which would be the best solution? Place? Article? Just Microformat?
Schema.org is quite flexible to mix elements as you wish, but so far Google will handle only some specific cases, the ones listed in their reference page
The more I am going into the depths of structured data makeup, the more complex and detailed it seems to become. One could even markup areas of the page like footer, header, sidebar, single menu elements etc., I guess a page could easily consist of 80% schema markup and 20% content when taken too seriously. :)
Is it really doing any good to add more than a rough markup skeleton (WebPage or Article) to the potentially hundreds of actual content pages of a website, and shouldn't one only include full author information along with business opening times, contact details etc. on a dedicated contact/business information page? I'm concerned about the bloat. Which kind of markup is recommended for certain types of pages and which of it can be left out because a search engine would compile the information from other parts of the website anyway?
If you only care about user-visible search result features in big seach engine services (e.g., Bing, Google Search, Yahoo! Search and Yandex, which all happen to sponsor Schema.org), the answer is easy: Provide what search engines document to recognize.
Are these user-visible search result features the only things search engines "do" with Schema.org structured data? Probably not. They’ll likely use structured data to better understand page content, and most likely to analyze what other features they could offer in the future. See for example Dan Brickley’s (he is Google’s Schema.org representative) posting about this. But all this is typically not documented by the search engines, of course. So if you care about this, too, the answer would be: Provide what is conceivable to be useful for search engines.
Are search engines the only consumers interested in Schema.org structured data? No, there are countless other consumers (services as well as tools). Enter the world of the Semantic Web and Linked Data. If you know and care about a consumer, the answer is easy again: Provide what this consumer documents to support. But you can’t know them all, of course. So if you care about all these (known and unknown, currently existing and still to appear) consumers, the answer would be: Provide what is conceivable to be useful for all consumers. Or, because the interest of these consumers varies widely, even: Provide what you can.
That said, there are certainly Schema.org types which are rarely useful to provide. A good example are the WebPageElement types, which, as you mentioned, can get used for page areas (header, footer, navigation, sidebar etc.). In my opinion, a typical web page shouldn’t provide these types.
If you care about file sizes, you’ll want to use Microdata/RDFa (because these syntaxes allow you to annotate existing content) instead of JSON-LD (because this syntax requires you to duplicate the content). With RDFa you’ll probably even save slightly more compared to Microdata.
However, structured data typically only represents a fraction of the markup/content anyway, even if you provide as much data as possible.
Instead of repeating "background information" on every page (for example, the full data about the business), you can make use of references: you define a URI for your business (or every other thing) on the page where you fully describe it, and use this URI as property value where applicable on other pages. This is possible with #id (JSON-LD, see an example), itemid (Microdata), and resource (RDFa). The only reason not do this is possibly lacking consumer support for such references (depending on the consumer / the use case, they might not get followed). A middle way might be to provide the item (about the business or any other thing) on every page, once with the full data, and in all other cases with a limited set of data (ideally what is visible on the page, or what is needed for a specific consumer). The URI gets used as identifier for each item, conveying that all these items are about the same thing.
I am looking to add JSON-LD data to our company's site and have been using the structured data testing tool to validate my schema data and it all seems ok.
My question though is whether the content in the JSON-LD schema needs to be human readable as part of the human readable page content as well?
Google guidelines on the matter.
At Google, our first priority is to help our users find relevant, engaging answers for their search queries. High-quality structured data must not create a misleading or deceptive experience for search users. It should be an up-to-date and accurate reflection of the topic and content already found on the page, such as text, images, and videos. For example:
Markup should not be used to hide content not visible to users in any form, since it might create a misleading or deceptive search experience. For example, if the JSON-LD markup describes a performer, the HTML body should describe that same performer.
Source - Google, Quality guidelines
While the actual code markup is pretty well explained, in Google developers docs, it is unclear where in a web page or on which pages the markup needs to occur and in what relation to the actual reviews that are aggregated.
For example, I see many pages around the web that are getting rich snippets with reviews, however when you visit the page, there are no visible reviews or indication of where those reviews are coming from. (Example Google search: radio connections Los Angeles )
I think this type of implementation may be against Google guidelines, but the guidelines are unclear. Do aggregateRatings need to reference where those ratings originate? Do they need to be on the same page as the individual reviews or ratings?
I'm talking in a strict 'white-hat' way, because it seems that to get the rich snippet in Google, the aggregateRatings do not actually need to reference or be connected anything and are essentially self-contained.
The Schema.org type AggregateRating doesn’t even offer a property to reference the single ratings, or to specify the source.
On top of that, not all aggregate ratings are based on ratings that are available online. Think of ratings collected per phone, paper etc.
Anyway, the guidelines for Google’s Reviews/Ratings Rich Snippets are only documenting in which cases Google Search would consider displaying this rich snippet for your page. If you don’t follow their guidelines (e.g., you don’t provide a property "required" by Google), the worst that happens is that no rich snippet is shown (leaving aside cases of intentional misleading or spamming). Google is just one of many Schema.org consumers, and there are plenty of useful Schema.org uses that don’t necessarily comply with one of Google’s Rich Snippets.
The vocabulary Schema.org does not require any properties.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Suppose someone is building you a CMS (Content Management System) from scratch. What are the most important features to include and why?
security - OWASP Top 10
user management & user roles
action and view permissions
content versioning and audit
some form of workflow and notifications
i18n support on literals and object versions
normalized database schema design
some form of content import-export
assets management and thumbnail generation for uploads
Valid XHTML (compressed with GZIP)
Rich text editing (e.g FCKeditor) which generates accessible markup
Valid and minified CSS and javascript (e.g using YUI)
automatically generated sitemaps.org document
integration with Google Analytics
automatic RSS feeds
open search support
print css and/or print versions of content
SEO consideration for duplicate content (e.g use of canonical tag)
I think from a developer's perspective it would be an open modular architecture. IMHO there are always things to add which the CMS platform isn't providing out of the box. Also, it should be database-based.
Existing modules should cover the most important tasks: news, contacts, documents, forums, shop, survey, events, image gallery, navigation, links, fulltext-search, login, newsletter, etc.
From the user's perspective I think that the content editor (WYSIWYG) is the most important piece. The ability to edit inside the "live" page is a great feature. Upload of images with automated resizing and the upload of files should be easy.
The existence of page/control and website templates is also very helpful when you're starting with a CMS. Versioning of documents/pages is also a often required feature and a work-flow engine, where there are authors who create content and editors who are allowed to unlock it.
RSS syndication is another important feature that should be available in a modern CMS.
For international site it very important that the CMS had some sort of built-in multi-lingual support.
Then I think a good CMS nowadays must provide tools for Search Enginge Optimization, e.g. there must be a way to define and insert search engine friendly URLs.
Not mentioned already: A CMS system should easily integrate into an existing software infrastucture, so interoparability is a strong requirement.
Example: If your CMS supported WebDav, you win Microsoft Office as editing tools without any extra expenses.
My number one requirement when choosing a CMS system is the ability to skin it easily and control the markup.
Users can be really fussy about getting the layout EXACTLY as they want.
1) WYSIWYG editor. Being able to edit HTML content as if it were in Microsoft Word. That includs the ability to upload your own images.
2) Creating new pages without query strings ie) not 'pages.aspx?pageid=5' but 'contact.aspx'
3) Additional features such as news, photo gallery, blog, user management, etc...
Personally I really like the CMS starter kit Microsoft has available on codeplex. It is very well done and uses XML file storage so it doesn't need a database!
In addition to the things that others have mentioned:
Caching
If you page comprises lots of "pieces" - e.g. a Banner pane, Left pane, Main pane, Right pane and Footer pane, and perhaps each of those will have multiple "widgets" in them, then the effort of constructing the page becomes significant (both in database calls, and in rendering at the web server). Having some intelligent caching that is able to detect when any of the underlying content blocks has changed will make a big different to performance
CMS Matrix may be a useful comparison resource of existing CMS products
The features you need the most will naturally depend on how the CMS is going to be used, and by whom. For some, licensing will be the greatest issue, while for others, some obscure requirement like support for TIFF files could be the thing.
If you want en extensive list of CMS features, take a look at CMS Feature Lists
When working with clients, I often heard a number of requirements that, in my opinion, had little to do with what a modern CMS really needs. Far too often emphasis was on features that should have been in the domain of template designers, such as support for responsive design (whatever that really means), the ability to add brand elements etc.
I compiled a list of the top 5 features a modern CMS needs at http://www.simoahava.com/content-management/modern-cms-top-5-features/
Modular architecture and strong security are the most important features from a technical standpoint. Complete control over content, source code and the software solution itself are all huge perks for any CMS.
Simo Ahava