Re: Schema.org v1.6 release candidate: Roles, various fixes, site navigation improvements

The examples for each of the Role types are out of step with others offered
on the site (at lease AFAIK).

More specifically, the content "Without Markup" tabs for every example for
every Role type is *not* the example without markup, but instead a
*description* of the example listed.

Compounding this mismatch between the tab title and content is the de facto
description itself.  For example, the content of the first "Without Markup"
tab under Role:

A basic Role example in JSON that
shows how to qualify the 'member' property
by adding an intermediate Role entity.

The other tabs then provide the example in RDFa, Microdata and JSON-LD -
everything but JSON!  Even if the description were modified to read "in
JSON-LD" it would still be inaccurate in that it omits the other example
types.

If there's desire to annotate examples in order to explicitly draw
attention to some aspect of the example, then the description of the
example can readily be placed outside of the tabs.  That is from the
current layout with the Role types:

Without Markup [selected] | Microdata | RDFa | JSON-LD
A description of the example

To:

A description of the example
Without Markup [selected] | Microdata | RDFa | JSON-LD
The example code without markup

Finally, while the blog post on Role in general provides a good overview of
the new types, I find "using the newly proposed 'athlete' property" (which
is introduced in the second sentence, and used in the first two
illustrative figures) as the primary example to be absurd.  Here's a new
type and we're going to demonstrate how it works by referencing a candidate
property you won't find documented in the published schemas?



On Mon, Jun 16, 2014 at 10:24 AM, Dan Brickley <danbri@google.com> wrote:

> ... and we're live! Thanks to everyone for discussion, bugfixes and
> more. I'll go through and update release notes later. I have to run
> now but I wanted to share the blog post
> http://blog.schema.org/2014/06/introducing-role.html which gives a bit
> more background on the Role design.
>
> Dan
>
> p.s. there is also very basic JSON-LD @context file support, curl -H
> "Accept: application/ld+json" http://schema.org/  ... this needs
> refining but is a step in the right direction. Dan Scott contributed
> in lots of ways but in particular added RDFa/RDFS to the per-term
> pages, which in turn nudged me into adding support for mapping to
> other schemas - see view src on http://schema.org/Dataset
>
>
> On 9 June 2014 21:39, Dan Brickley <danbri@google.com> wrote:
> > There is a temporary review build of schema.org v1.6 for your
> consideration.
> >
> > The main improvement is the addition of a minimalistic Role mechanism,
> > alongside other
> > navigation and bug fixes.
> >
> > Draft release notes copied below. See also
> >
> https://docs.google.com/a/google.com/document/d/1RSe6zr--DuIk9AzJyuMfOzw4_kc-DwPbgx2IH9LiCzs/edit?disco=AAAAAJnB6Ew#
> > for background on the Role design.
> >
> > Careful schema.org watchers might notice that the approach to Role
> > here is different (hopefully
> > similar) to our last "we think we're done" design. This approach
> > introduces less additional vocabulary, and can be extended later. For
> > now we believe it addresses important use cases that arise when
> > describing situations from sports and music. The draft site includes
> > several
> > JSON-LD examples to illustrate the approach.
> >
> > Please take a look. There are a few ongoing improvements, but we hope
> > to make these changes live in the near future. The test build is
> > available currently at http://sdopending.appspot.com/ therefore useful
> > entry points mentioned below include...
> >
> > http://sdopending.appspot.com/Role
> > http://sdopending.appspot.com/OrganizationRole
> > http://sdopending.appspot.com/PerformanceRole
> > http://sdopending.appspot.com/startTime
> > http://sdopending.appspot.com/endTime
> > http://sdopending.appspot.com/Question
> > http://sdopending.appspot.com/TheaterEvent
> > http://sdopending.appspot.com/acceptedAnswer
> > http://sdopending.appspot.com/object etc.
> >
> > Note that these changes are all just on the test site, so change
> > 'schema.org' to '/sdopending.appspot.com' in the notes below to find
> > the release candidate version.
> >
> > cheers,
> >
> > Dan (for schema.org)
> >
> > -------------------------
> >
> > Changes in 1.6 (draft release notes)
> >
> > Vocabulary
> >
> > 1) Role
> >
> > * Added a Role type, for describing "additional information about a
> > relationship or property."
> > * Added two sub-types of Role, OrganizationRole and PerformanceRole.
> > * Added a property that applies to each ('namedPosition',
> > 'characterName' respectively).
> >
> > 2) license
> >
> > * Added a 'license' property, by popular demand. Will add an example
> > based on something like
> >
> http://ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2010/video-lectures/lecture-12-graphs-networks-incidence-matrices/
> >
> > Errata and site improvements
> >
> > 3) Tidied the description of properties that are used primarily within
> > schema.org, in definitions and site navigation.
> >
> > * http://sdopending.appspot.com/Property and
> > http://sdopending.appspot.com/Class should have been marked as
> > Intangible.
> > * documented 'supercededBy', "Relates a property to one that supercedes
> it."
> > * documented 'inverseOf', "Relates a property to a property that is its
> inverse.
> >
> > Inverse properties relate the same pairs of items to each other, but
> > in reversed direction. For example,
> > the 'alumni' and 'alumniOf' properties are inverseOf each other. Some
> > properties don't have explicit
> > inverses; in these situations RDFa and JSON-LD syntax for reverse
> > properties can be used."
> >
> >
> > 4) typo in 'diet' property:
> > -      <span property="rdfs:comment">A sub property of instrument. The
> > died used in this action.</span>
> >  +      <span property="rdfs:comment">A sub property of instrument.
> > The diet used in this action.</span>
> > (thanks, Dan Scott)
> >
> > 5) QAPage
> >
> > Removed unnecessary QAPage type from the main Question/Answer example,
> > as it wasn't adding anything useful.
> > We encourage feedback on the value of this type, which can be used to
> > describe pages that bundle a Question with
> > its Answer(s).
> >
> > Added JSON-LD example for Question/Answer vocabulary.
> >
> >
> > 5) defaultValue's definition had 'Literal' instead of 'Text'.
> >
> > https://github.com/rvguha/schemaorg/pull/33/commits
> >
> > (yes, we're on Github now, if you read this far; more on that later).
> >
> > Reported by Simon Spero, fix prepared by Stephane Corlosquet.
> > Mistaken use of Literal in definition of default value property.
> >
> > http://lists.w3.org/Archives/Public/public-vocabs/2014May/0193.html
> >
> > -      <span>Range: <a property="http://schema.org/rangeIncludes"
> > href="http://schema.org/Literal">Literal</a></span>
> > +      <span>Range: <a property="http://schema.org/rangeIncludes"
> > href="http://schema.org/Text">Text</a></span>
> >
> >
> > 6) Sub-property (rdfs:subPropertyOf)
> >
> > We note that sometimes properties have a sub-property / super-property
> > relationship.
> >
> > Added assertions where this is the case, for the following pairs:
> >
> > (the 1st is sub-property, i.e. the more specific; 2nd url is
> > super-property, i.e. the more general)
> >
> > <http://schema.org/acceptedAnswer> <http://schema.org/suggestedAnswer>
> > <http://schema.org/borrower> <http://schema.org/participant>
> > <http://schema.org/buyer> <http://schema.org/participant>
> > <http://schema.org/candidate> <http://schema.org/object>
> > <http://schema.org/collection> <http://schema.org/object>
> > <http://schema.org/course> <http://schema.org/location>
> > <http://schema.org/deliveryMethod> <http://schema.org/instrument>
> > <http://schema.org/diet> <http://schema.org/instrument>
> > <http://schema.org/distance> <http://schema.org/asset>
> > <http://schema.org/endorsee> <http://schema.org/participant>
> > <http://schema.org/entertainmentBusiness> <http://schema.org/location>
> > <http://schema.org/exercisePlan> <http://schema.org/instrument>
> > <http://schema.org/followee> <http://schema.org/object>
> > <http://schema.org/foodEstablishment> <http://schema.org/location>
> > <http://schema.org/foodEvent> <http://schema.org/location>
> > <http://schema.org/fromLocation> <http://schema.org/location>
> > <http://schema.org/landlord> <http://schema.org/participant>
> > <http://schema.org/language> <http://schema.org/instrument>
> > <http://schema.org/lender> <http://schema.org/participant>
> > <http://schema.org/loser> <http://schema.org/participant>
> > <http://schema.org/opponent> <http://schema.org/participant>
> > <http://schema.org/option> <http://schema.org/object>
> > <http://schema.org/query> <http://schema.org/instrument>
> > <http://schema.org/question> <http://schema.org/object>
> > <http://schema.org/realEstateAgent> <http://schema.org/participant>
> > <http://schema.org/recipe> <http://schema.org/instrument>
> > <http://schema.org/recipient> <http://schema.org/participant>
> > <http://schema.org/replacee> <http://schema.org/object>
> > <http://schema.org/replacer> <http://schema.org/object>
> > <http://schema.org/resultReview> <http://schema.org/result>
> > <http://schema.org/sender> <http://schema.org/participant>
> > <http://schema.org/sportsActivityLocation> <http://schema.org/location>
> > <http://schema.org/sportsEvent> <http://schema.org/location>
> > <http://schema.org/sportsTeam> <http://schema.org/participant>
> > <http://schema.org/toLocation> <http://schema.org/location>
> > <http://schema.org/vendor> <http://schema.org/participant>
> > <http://schema.org/winner> <http://schema.org/participant>
> >
> >
> > Note: during this process, we re-evaluated
> > http://schema.org/musicGroupMember and
> > http://schema.org/member - and decided that the latter addresses all
> use cases.
> > Marked 'musicGroupMember' as superceded by 'member'. Further cleanup
> > is needed around the
> > expected types for 'member' and 'memberOf'.
> >
> >
> > 5. Inverse Properties
> >
> > We note that sometimes properties have an inverse relationship. We
> > have added supporting vocabulary
> > and site-generation code to support this, and have documented it for
> > the case of the alumni/alumniOf pair.
> >
> > We encourage suggestions for other pairs of schema.org properties that
> > are inverses.
> >
> >
> > 6. TheatreEvent
> >
> > update TheatreEvent with improved example(s). Microdata/RDFa also
> updated.
> >
> >
> > 7. Site Navigation
> >
> > Per-property pages have inverses, super/sub properties, and tooltips
> > on mouseover. Need to add supercedes/supercededBy.
> >
> > 8. Definition errors (repeated text etc)
> >
> > Several fixes to repeated definition issue highlighted by Simon Spero
> > in http://lists.w3.org/Archives/Public/public-vocabs/2014May/0193.html
> >
> > Fixing ambiguously mis-defined "departTime" property. It was
> > mis-identified in our configuration as "startTime" and so the proposed
> > "departTime" property never existed. Given that we already have
> > "departureTime" (transport-related), and that 'startTime' already has
> > the issue of applying both to FoodEstablishmentReservation
> > and to Action, the "departTime" notion should be handled by endTime.
> >
> > Adjustments to startTime and endTime definitions so that they apply to
> > event reservations and
> > to Action.
>
>