Implement the new extensions model #429
Meta bug. See discussion thread https://lists.w3.org/Archives/Public/public-vocabs/2015Mar/0117.html
Related: draft bib: extension #431 https://lists.w3.org/Archives/Public/public-schemabibex/2015Apr/0000.html
First cut code was merged from sdo-scripts into sdo-gozer, April 27th.
For any running installation of the schema.org site, ... considering a base domain such as 'schema.org', 'sdo-gozer.appspot.com', 'webschemas.org' etc., here written BASE_DOMAIN:
Data loading and internal APIs
As with schema.org core, all schemas and examples are deployed as part of site updates; they are not loaded dynamically from the Web. This first extensions implementation only addresses reviewed/hosted extensions (e.g. "bib.schema.org") and has no treatment of external extensions, i.e. those on external domains.
The text was updated successfully, but these errors were encountered:
It would be nice to simply use GitHub (and Git clients) Search to easily find same or similar named properties, types, etc. across core and extensions (to help with aligning extensions and core, etc).
Q: I think putting extensions themselves in a separate parent folder in the repository (instead of under /data ) might help even more with filtering mechanisms (path) in GitHub extensions and Git clients that many of us use ? Although symbolic links and aliases can help on the client side, second thought.
In pursuit of the above, I've been wiring in the JINJA2 template engine (#459). The homepage is now composed via script-capable templates from templates/*tpl. The variables exposed to the templates are currently too chaotic and shouldn't be considered a stable API. We can rationalize those naming choices once the thing is in a functioning state.
First pass ready for evaluation and comment. 'bib' extension proposal implemented to to view.
Enhancement to rdfa files
New element required for classes and properties to associate them with an extension:
<div typeof="rdfs:Class" resource="http://schema.org/Chapter"> <link property="http://schema.org/isPartOf" href="http://bib.schema.org" /> <span class="h" property="rdfs:label">bib:Chapter</span> <span property="rdfs:comment">One of the sections into which a book is divided. A chapter usually has a section number or a name.</span> <span> Subclass of:<a property="rdfs:subClassOf" href="http://schema.org/CreativeWork">schema:CreativeWork</a> </span> </div>
Note: The 'http://schema.org/isPartOf' definition is only required for new [across all extensions & core] terms. The default is to be partOf http://schema.org hence it is not required in core rdfa files. It is also not required when adding extension specific details to an already defined term - eg. Adding to the range of a property:
<div typeof="rdf:Property" resource="http://schema.org/pageEnd"> <span class="h" property="rdfs:label">schema:pageEnd</span> <span>Domain:<a property="http://schema.org/domainIncludes" href="http://schema.org/Chapter">bib:Chapter</a></span> </div>
Display / Navigation of terms in hosted extensions
Identifying terms from an extension
See example: http://bib.sdo-ganymede.appspot.com/Audiobook
<code property="rdfs:label"><a class="ext-bib" href="/readBy">readBy</a>*</code>
Identifying potential properties from extensions when displaying in core
See example: http://sdo-ganymede.appspot.com/Book
Navigation to extension definition
…org (#727) Cleaned up navigation after v2.1. Made navigation through menus and docs consistent as to when to remain in an extension or to force to basic schema.org. Included making schemas.html into a template. Also maintains the http/https state through a user session. Corrected thread based caching of global variables errors that were introduced with extensions - reset temporary fix of threadsafe=false in app.yaml. Introduced a /_siteDebug page to monitor cache usage and settings etc. Issues: (#429) - Completing the initial extensions model (#732) - Docs links for menus now go to base url (#716) - Preparing ground by at least being in session consistent