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

On 16 June 2014 20:13, Aaron Bradley <aaranged@gmail.com> wrote:
> 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.

Yes, we got into that habit with the JSON-LD-led Actions examples. For
Role, all the examples were also initially JSON-LD, you're right the
first tab ought to have the pre-schema markup.

> 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!

JSON-LD is JSON, but yes, it needs updating.

Re athelete below, we have a proposal about to be circulated at which
point I'll link http://sdo-sports.appspot.com/athlete from the blog
post. Sports (and Music) were big 'sanity check' use cases for this
approach, so it's good to be clear about that rather than using less
realistic examples.

cheers,

Dan

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

Received on Monday, 16 June 2014 21:43:46 UTC