> In terms of vocabulary, Schema.org is “extensible” via several mechanisms including mashups with other vocabularies or, ideally, direct integration into the Schema.org namespace such as we’ve seen with RNews <http://blog.schema.org/2011/09/extended-schemaorg-news-support.html> , JobPostings <http://blog.schema.org/2011/11/schemaorg-support-for-job-postings.html> , and GoodRelations <http://blog.schema.org/2012/11/good-relations-and-schemaorg.html> . This is a win/win scenario, but it requires communities to prove they can articulate a sensible set of extensions and deliver the information in that model. Within the “bibliographic” community, this is the mandate set for the http://www.w3.org/community/schemabibex/ group. If you are disappointed with OpenURL metadata formats, poor support for COinS, and disappointing probabilities for content resolution, here’s your chance for leveraging SEO for those purposes.
But... it is no good choosing a random extension if the Search engine
is or will be blind to that particular method.
As someone who likes to leverage SEO the "right" way so one does not
get penalised, some standardisation is needed.
Dave Caroline, waiting