New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
danbri opened this Issue Mar 29, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@danbri
Contributor

danbri commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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.

Contributor

danbri commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Mar 29, 2016

Contributor

+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

Contributor

Dataliberate commented Mar 29, 2016

+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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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.

Contributor

danbri commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

I made a test of a pending proposed property:

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

Contributor

danbri commented Mar 29, 2016

I made a test of a pending proposed property:

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

danbri added a commit that referenced this issue Mar 29, 2016

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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.

Contributor

danbri commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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).

Contributor

danbri commented Mar 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@webmaven

webmaven May 21, 2016

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.

webmaven commented May 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri
Contributor

danbri commented Aug 10, 2016

@danbri danbri closed this Aug 10, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment