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.

TODOs

Site navigation

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:

• foo.BASE_DOMAIN/Person (since Person is a term defined in the core, and 'foo' is a hypothetical extension) should display as normal, while indicating that we are viewing the 'foo' extension.
• xyz.BASE_DOMAIN/Person etc. should completely fail, e.g. 404 or browser resolution error, if 'xyz' is not enabled as an extension name on that installation.
• foo.BASE_DOMAIN/XyzAbc should fail by 404 if XyzAbc is not a known term in any enabled extension running on that installation.
• BASE_DOMAIN/Globe should fail with a helpful 404, with links to each extension e.g. 'foo' which defines/mentions the term 'Globe' (or any term that is known to an extension enabled in that installation).
• foo.BASE_DOMAIN/Globe should succeed, rendering a per-term page describing Globe, assuming Globe is a term defined in an extension 'foo' enabled on that installation. Navigation to related terms from core and from within 'foo' by normal means, i.e. Place, Event, CreativeWork, name etc from core would be listed and navigable "within the extension". STATUS: http://bib.webschemas.org/Globe?ext=bib works but needs the ext=bib still.
• foo.BASE_DOMAIN/ should present a simple homepage for the extension, including a short description of its purpose/scope, and a link to github for development. It should also list all terms defined by the extension, including their (e.g. supertype, subtype) connection to the core. This assumes content-type requested was text/html.
• foo.BASE_DOMAIN/docs/datamodel.html and other generic documentation should redirect transparently to BASE_DOMAIN/docs/datamodel.html to avoid proliferation of multiple URLs for the same static content.
• foo.BASE_DOMAIN/docs/xyz where xyz is jsonldcontext.json.txt, jsonldcontext.json, tree.jsonld, or full.html needs more thought. These are dynamically generated from "the" schema. Should we replicate per extension? Perhaps move them to a separate path e.g. /data/ or /versions/current/ ?
• foo.BASE_DOMAIN/ when content type requested is 'application/ld+json' should be a JSON-LD context file, however exact form needs consideration.
• HTML class attributes are set in the when we are in an extension mode, although the default style sheet currently does not make great use of this.
• BASE_DOMAIN/ for e.g. CreativeWork should have some link (under 'more...', or lower in page below core vocab) to foo.BASE_DOMAIN/Xyz if Xyz is a subtype, supertype, subproperty, superproperty of CreativeWork in an enabled extension 'foo' on this installation. STATUS: http://webschemas.org/CreativeWork has 'mentions' under 'more...', although the cross-links use url params currently.

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.

• schema data is read from data/ext/{xyz}/*.rdfa files, loaded schema graphs named as layers 'xyz', 'bib' etc, following the folder names.
• extension-specific examples should be read from data/ext/{xyz}/*txt files, following the format conventions of core schema.org.
• Many functions in api.py now take an optional argument (defaulting to 'core') that lists the layer(s) to be applied.
• There is a notion of current active extension. The default is no extension, i.e. we view only 'the core'. If we are in xyz.BASE_DOMAIN/ then our current active extension is 'xyz'. Current active extension is set by inspecting actual domain and comparing to BASE_DOMAIN.
• Although there is internal API support (and debugging via URL parameters, ?ext=foo,bar,abc,...), we do not offer public support for navigating multiple extensions simultaneously. Most users will either be looking at a term in the core, a term defined in the extension, or a core term navigated within an extension.

Testing

• Where BASE_DOMAIN is the webschemas.org installation (using a test domain similar to schema.org for clarity)
• 'bib' is a work-in-progress (test data only currently) reviewed/hosted extension enabled in this installation, and loaded from data/ext/bib/*rdfa
• 'Globe' is a term defined in the bib: extension (although the actual bib extension may not eventually define it, the term is useful for testing here...)

Test URLs:

• http://webschemas.org/Person - core term in core. Expect this to navigate as in classic 'Person' (i.e. schema.org/Person), including some basic discoverability of links into extensions where extension has terms related to Person. STATUS: crude cross-links under 'more...' .
• http://bib.webschemas.org/Person - core term, viewed from bib extension. Expect classic navigation of Person but with a header telling us this is the the bib extension. Top of page should be 'bib.schema.org' hyperlinked to front page.
• http://qwertyuiop.webschemas.org/Person - core term, bogus extension subdomain. Expect: failure to load in browser.
• http://bib.webschemas.org/Globe - a term defined in (this version of) bib: extension, and navigated within Bib extension.
• http://bib.webschemas.org/ - front page of bib extension. Expect a short intro with links to all or main terms for the extension.
• http://webschemas.org/Globe - Looking in the core site for a term from an extension, 'Globe', that is not in the core. a 404 or 404-like page, saying that "Globe" is not in the core but listing links to extensions that define or describe it.