Google has announced some extensions for Schema.org that aren't currently documented on the Schema.org site, like Software Applications. Google announced that on Sept 14, and it seems like it is still not documented on Schema.org. While the terms would be simple to add to this module, I don't know if you want to support terms that aren't listed on Schema.org itself.

I bring this up because I'm working on a project that requires modeling of Software Applications. Since RDFa is now supported by Google for Rich Snippets, and since I can use Field Collection and don't need any compound fields (at least, I don't think), it seems like I could use RDFa and this module to get running on this project quickly. However, for it to be easy for people, there would need to be support for the Software Applications class and properties.

Have you already given thought to how to handle the browsers' independent extensions of Schema.org?

CommentFileSizeAuthor
#3 1296560-software-application.patch13.6 KBlinclark

Comments

scor’s picture

scor commented

+1. I don't see why not... as long as there is some usage that somehow indicates this terms is useful. Note that even of the type is not in the autocomplete list, there is nothing that prevents you from using it already (just beware of typos!), in other words, there is no FAPI validation of the schema.org terms.

Have you already given thought to how to handle the browsers' independent extensions of Schema.org?

browsers' independant? hum, did you mean search engines here?

Anonymous’s picture

Anonymous (not verified) commented

Ha, right, totally meant search engines. Google is just in too many businesses these days ;)

Anonymous’s picture

Anonymous (not verified) commented
Title: Support for Google's Schema.org extensions? » Add support for Google's SoftwareApplication
Status: Active » Needs review
StatusFileSize
new 1296560-software-application.patch13.6 KB

Ok, I added the terms from Google's doc page on SoftwareApplication. I'm not sure whether it should be committed yet though, because looking at the terms it seems like they are going against the general Schema.org way of doing things in some instances, so I'm not sure if it's stable yet.

scor’s picture

scor commented

On my way back from Austin, I was thinking about the best way to handle official and unofficial terms. I came to the conclusion that it's probably best to keep the unofficial terms in a separate json file, and merge them with the official terms when pulling updates from schema.rdfs.org. That way we can keep track more easily (in git) of the changes we made to the unoffical terms, which might get lost otherwise in the massive amount of official terms. I was thinking both sources could be merged on the fly by the client javascript, but that would cost an extra http request, and some extra processing, so probably best to ship the module with the combined terms json file.

So this is the structure I'm thinking of:
js/schemaorg.js (module js)
js/schemaorg.terms.json (terms which are downloaded clientside combined official + unofficial)
js/src/schemaorg.custom-terms.json (unofficial terms used by the drush command to generate the terms file)

the custom json file is purposely located in its own src directory to emphasize it's not used on the client side. It does not even need to be in json, if it makes authoring easier, it could simply be a PHP array that the drush script uses during the json generation (the official json is parsed into an array of objects too to strip the elements we don't need, that's why I'm suggesting having the custom unofficial terms in a PHP format).

thoughts?