W3C home > Mailing lists > Public > public-vocabs@w3.org > June 2014

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

From: Dan Brickley <danbri@google.com>
Date: Wed, 18 Jun 2014 14:26:48 +0100
Message-ID: <CAK-qy=6dtqAP==byEfktK5LsEEv-N+4yS=23i7H6PcoLF0gAUA@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: "<public-vocabs@w3.org>" <public-vocabs@w3.org>, Robina Clayphan <Robina.Clayphan@kb.nl>
On 18 June 2014 14:15, Antoine Isaac <aisaac@few.vu.nl> wrote:
> Hi Dan,
>
> As you know already, I like very much that there's a license property. It
> will be very useful for us at Europeana!
>
> My colleague Robina however spotted that the value expected for
> http://www.schema.org/license is  CreativeWork, URL
> And the doc says "A license document that applies to this content, typically
> indicated by URL."
>
> Does this include *real* licenses URIs like
> http://creativecommons.org/licenses/by/4.0/
> ?

Like in the last example in http://schema.org/WebPage ? :)

(I realise readers don't know what is in each example 'tab' until they
look... maybe we could improve that)

<body vocab="http://schema.org/" typeof="WebPage">
  <h1 property="name">Lecture 12: Graphs, networks, incidence matrices</h1>
  <p property="description">These video lectures of Professor Gilbert
    Strang teaching 18.06 were  recorded in Fall 1999 and do not
    correspond precisely to the current  edition of the textbook.</p>
  <div property="publisher" typeof="CollegeOrUniversity">
    <h4 class="footer">About <span property="name">MIT
OpenCourseWare</span></h4>
  </div>
  <a rel="license"
href="http://creativecommons.org/licenses/by-nc-sa/3.0/us/deed.en_US"><img
    src="/images/cc_by-nc-sa.png" alt="Creative Commons logo with
terms BY-NC-SA." /></a>
</body>

(note that this RDFa dips into full RDFa 1.1 rather than lite, so that
the @rel attribute can be used)

> I know this touches on a debate on 'real things vs URLs' that has surfaced
> on the list quite a lot. I'm aware schema.org has actually quite a
> permissive stance about this, and don't want to resurrect the debate - if
> just because the word "license" itself may refer to the higher-level a set
> of requests/permissions, or the document that records it.
> I just wanted to check that it was alright to use CC license URIs directly
> with schema:license!

CC is a great use of this property. Schema.org doesn't attempt to
model in detail what those documents say or mean, but the property
gives a place to go read to find out more. This might be particularly
useful for famous urls like CC licenses.

Dan

> Actually even erring on the ontological side of things I'll find it alright
> to consider the license-as-agreement as a CreativeWork, too, which would
> alleviate all doubts. Unless there are plans to introduce classes like
> 'Contract' later in schema.org, which would jeopardize this soft stance to
> what licenses are. I believe/hope it's not the case yet!
>
> Best,
>
> Antoine
>
> --------
>
>
> On Mon, Jun 9, 2014 at 1:39 PM, 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.
> --
> Antoine
>
Received on Wednesday, 18 June 2014 13:27:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:42 UTC