> > > 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