Conversation
…ected containedInPlace renaming and containsPlace inverse property, added Room class and moved roomNumber thereto
…ed property, and associated changes
… as itemOffers as its range)
|
Dear Dan, |
|
@mfhepp I'll convert it into a pending.schema.org extension this week, and propose it to go out imminently with a 3.1 release. |
|
thanks! martin hepp
|
|
Upon consideration I think this is not a good fit for pending, so let's do it in one hop. Pending works well when we are purely adding new vocabulary; here there are lots of integration points with the existing core. |
| <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Demand">Demand</a></span> | ||
| <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Product">Product</a></span> | ||
| <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Service">Service</a></span> | ||
| <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Accommodation">Accommodation</a></span> |
There was a problem hiding this comment.
Why are we adding Accommodation to itemOffered? Shouldn't authors use MTEs (Accommodation and Product/Service as appropriate) for this?
There was a problem hiding this comment.
On 19 Jul 2016, at 18:41, vholland [email protected] wrote:
In data/schema.rdfa:
@@ -5592,6 +5613,7 @@ Note that Event uses startDate/endDate instead of startTime/endTime, even when d
Domain: Demand
Range: Product
Range: Service
<span>Range: <a property="http://schema.org/rangeIncludes" href="proxy.php?url=http://schema.org/Accommodation">Accommodation</a></span>Why are we adding Accommodation to itemOffered? Shouldn't authors use MTEs (Accommodation and Product/Service as appropriate) for this?
- Because MTEs do not work (as of now) in Google's toolchain, so anybody adopting this would battle with validation errors.
- Because we agreed on that design in the conference call a few months ago.
- Because many of the properties of Product/Service are not really applicable to hotel rooms etc. (e.g. GTIN).
Also, we want to point people to the fact that an offer can include a hotel room etc.
While in GoodRelations, Product was essentially a role notion for Thing, implying that it is the object in an offer, we silently narrowed Product in schema.org to commodities. You can see this also in the fact that Service is not subtype of Product in schema.org, while it is included in the ProductOrService class in GR.
|
re http://sdo-hotels.appspot.com/Accommodation @mfhepp @vholland should we hop onto a skype/hangout/phone call to talk this through? We have an awkward little shopping list of terms on 'itemOffered' and another on 'offers'. Should we be trying to keep those two in sync, at least? |
|
Here's what I suggest. I will merge this into sdo-makemake (our work in progress towards a v3.1 release), but I do not feel confident proposing the resulting design as a consensus candidate release to our steering group, since we have at least 2 steering group members here (Vicki and Martin) still working out some details. I'm confident we'll figure something out and the merge covers a lot of useful ground, so let's get all our drafts in one place for serious review and finalization. |
|
Merged and ran tests. I get some errors: I am commenting out mentions of that type for now. @mfhepp please advise! |
|
Ok the tests now pass, so I have pushed this out to our work-in-progress site, http://webschemas.org/docs/hotels.html TODO: Note that we will need to add an entry to docs/releases.html summarizes this change. |
|
Searching around, I found https://schema.org/SingleFamilyResidence and assume now that SingleFamilyHome was intended as a reference to this (long existing) type. I will re-instate the references but to SingleFamilyResidence if @mfhepp can confirm this was the intended design. |
…leFamilyHome was wrong. See #1224
|
I've gone ahead and made that change (SingleFamilyHome -> SingleFamilyResidence). |
|
@danbri I think the (SingleFamilyHome -> SingleFamilyResidence) is fine. |
|
On 19 Jul 2016, at 18:39, Dan Brickley [email protected] wrote:
It can of course be applied to other entity types, but the consensus in our conference call was to start small and expand it later as needed. Feel free to broaden the domain if you think this is appropriate. Martin |
|
On 19 Jul 2016, at 18:52, Dan Brickley [email protected] wrote:
Yes, they should be in sync; feel free to add more classes to itemOffered. Note that this is the consequence that schema.org did not adopt the design pattern in GoodRelations of having all tradeable things as a subtype of ProductOrService. Because you did not want this, we have to tweak the domains and ranges whenever we discover that a new type of things can be part of an offer (e.g. CreativeWork), and this will go on as the scope of schema.org emerges. Also note that an Event can, in my understanding, not really be offered. You can offer access or other rights to / on an event, as we did in the Tickets Ontology, see http://www.heppnetz.de/ontologies/tio/ns. But be it like it is; the growing inconsistency in schema.org is the result of premature optimizations decided upon the in the past years when conceptual clarity was sacrificed for perceived simplicity for Web developers in particular use-cases. Martin |
3 participants
This pull-request addresses #915 and supersedes #916.
I implemented all the changes as agreed in #915 (comment).
The following minor additions or modifications turned out to be necessary:
I also implemented a few additional improvements, e.g. links from core types to /docs/hotels.html.
The changes are very transparent due to the many small commits in my fork at https://github.com/mfhepp/schemaorg/commits/hotels-v2.
A preview of this work is available at: