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

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/
?

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!

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:15:50 UTC