Create hosted extensions for internal admin terminology ("meta.") and things-being-discussed ("pending")

[danbri]

Now that we have the hosted extensions mechanism, we can use it better within our own workflow and site administration infrastructure.

meta

Currently we have several terms in schema.org which are not intended for widespread public usage, but serve as necessary machinery for structuring our schema descriptions. I propose to migrate these into a "meta.schema.org" extension where they can be more clearly documented as such: at least supersededBy, domainIncludes, RangeIncludes. We still need to add a better mechanism for type and enum deprecation too, that would also live under 'meta'.

pending

Currently it is hard for casual participants, and also busy Steering Group members, to keep track of the status of various proposals. Github Pull Requests are naturally very oriented towards implementation detail. Proposal authors sometimes set up ad-hoc temporary *.appspot.com copies of schema.org to illustrate draft proposals, but these can also be hard to keep track of. The proposal here is to add an explicit "pending.schema.org" hosted extension subdomain where relatively mature, substantive or attractive drafts can be included for easier and more widespread review.

[danbri]

Q: should parties creating a pull request for new vocabulary put their terms into data/schema.rdfa or into data/ext/pending/issue-number.rdfa ?
A: either should be fine as we explore this mechanism and get a sense for how well it works.

[Dataliberate]

+1 to main proposal.

I would suggest putting proposals, that are not for a new hosted extension, into data/pending should be placed as you describe as a default. (Proposals for new extensions into an appropriately named data/ext subdirectory).

There should be exceptions to this when adjusting terms already in data/schema.rdfa, such as changing super-type, changing a domain/range, or changing comment text. Just adding a domain/range should be done in pending.

~Richard

[danbri]

I think we ought to treat this as a real extension, otherwise it opens a route for subtle bugs. As you say this limits the kinds of proposed changes we can record this way, but I believe that would be true of data/pending too.

[danbri]

I made a test of a pending proposed property:

• http://pending.webschemas.org/contentReferenceTime

Currently you need to look under 'more...' to dig out the link to the original proposal at Github, #1050

[danbri]

There's a bug currently - http://meta.webschemas.org/Class has 'defined in the None extension' despite sdoapp.py having 'meta' enabled and the files being read from data/ext/meta/*.rdfa successfully. Investigating.

[danbri]

Fixed. http://meta.webschemas.org/Class works (although you may need 66.102.1.121 in your etc/hosts file while waiting for the DNS addition to propagate).

[webmaven]

The documentation page for the full schema of an extension (eg. http://pending.schema.org/docs/full.html or http://meta.schema.org/docs/full.html) should probably default to displaying the extension alone rather than core + extension.

I also suggest that clicking the radio options should update the browser url with a fragment identifier (eg. http://pending.schema.org/docs/full.html#ext or http://schema.org/docs/full.html#all, etc.) such that navigating away from the page and back maintains the state of what is displayed.

[danbri]

Published - see http://schema.org/docs/releases.html