Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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.
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.
This was referenced
Apr 17, 2015
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.
added a commit
May 19, 2015
referenced this issue
Jul 23, 2015
added a commit
Jul 23, 2015
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