Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vocabulary for hotels, vacation homes, camping sites, etc. #915

Open
mfhepp opened this issue Dec 3, 2015 · 45 comments
Open

Vocabulary for hotels, vacation homes, camping sites, etc. #915

mfhepp opened this issue Dec 3, 2015 · 45 comments
Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!). schema.org vocab General top level tag for issues on the vocabulary status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area. type:tricky problem Hard problems, including modeling / vocabulary and infrastructural aspects (eg fiction, probability)

Comments

@mfhepp
Copy link
Contributor

mfhepp commented Dec 3, 2015

We need a vocabulary for expressing hotel information, namely about the lodging business, room categories, and rates.

@mfhepp
Copy link
Contributor Author

mfhepp commented Dec 3, 2015

This issue is related to

#780
#241

@vholland
Copy link
Contributor

vholland commented Dec 4, 2015

Here are some quick thoughts. It would help with reviewing if there were more examples, as the usage is not always clear. Please let me know if anything is unclear.

  • There are many generic names, which may haunt us in the future. The following are suggested changes:
    • schema.org/AccommodationFeature -> schema.org/AccommodationFeatureSpecification
    • schema.org/feature -> schema.org/accommodationFeature
    • schema.org/includedFeature -> schema.org/includedAccommodationFeature
    • schema.org/optionalFeature -> schema.org/optionalAccommodationFeature
    • schema.org/permittedUsage -> schema.org/permittedAccommodationUsage
    • schema.org/bed -> schema.org/accommodationIncludesBed
    • schema.org/occupancy -> schema.org/maximumOccupancy
    • accommodationSize seems like an odd name for square footage. Is there a more apt name?
  • Can we avoid adding Accommodation as a child of both Place and Product? It would seem better to have authors use multiple types as appropriate.
  • What is the difference between schema.org/feature and schema.org/includedFeature?
  • Is mealService a property of the accommodation or of a reservation at the hotel or resort?
  • Can we combine petsAllowed and smokingAllowed under a broader enumeration instead of having booleans?
  • What is an accommodation feature? Do you have examples? It seems this might be more flexible if it were modeled as extra amenities offered by the hotel/resort, but I am not sure of the intended meaning. For example, can we move mealService here?
  • Why not add schema.org/bed to schema.org/Accommodation instead of specific subtypes?
  • For real estate listings, is there a way to list bathrooms? (They are excluded from schema.org/numberOfRooms)
  • Can we reuse schema.org/hoursAvailable instead of introducing schema.org/availabilityTimes?
  • I am not sure I understand schema.org/starRating. Can we instead expand to have a "ratedBy" property?
  • Can we create a larger physical access enumeration in place of "gated". For example, some hotels allow the public to buy day passes to the pool. Perhaps this combines with my earlier question about optionalFeature.
  • What is the difference between schema.org/CampSite and the existing schema.org/Campground?

@danbri
Copy link
Contributor

danbri commented Dec 12, 2015

@mfhepp - any thoughts on these questions?

@mfhepp
Copy link
Contributor Author

mfhepp commented Dec 14, 2015

will reply in detail asap

On 12 Dec 2015, at 21:32, Dan Brickley notifications@github.com wrote:

@mfhepp - any thoughts on these questions?


Reply to this email directly or view it on GitHub.

@danbri
Copy link
Contributor

danbri commented Dec 18, 2015

thanks!

@vholland
Copy link
Contributor

@mfhepp I have lost track on where we are with this. Can you send out an update?

One quick question I have is around buying vs renting. This would add a new House type with the idea of renting the House. How would you model a house sale? Make it the itemOffered in an Offer?

@vholland
Copy link
Contributor

The conversation has spanned a few different issues, so I am not sure where best to update, but my outstanding questions/comments are:

  • Can we avoid adding Accommodation as a child of both Place and Product? It would seem better to have authors use multiple types as appropriate. Otherwise, almost any type should be co-typed as a Product.
  • There are many generic names, which may haunt us in the future. The following are suggested changes:
    • schema.org/AccommodationFeature -> schema.org/AccommodationFeatureSpecification
    • schema.org/feature -> schema.org/accommodationFeature
    • schema.org/includedFeature -> schema.org/includedAccommodationFeature
    • schema.org/optionalFeature -> schema.org/optionalAccommodationFeature
    • schema.org/permittedUsage -> schema.org/permittedAccommodationUsage
    • schema.org/bed -> schema.org/accommodationIncludesBed
    • schema.org/occupancy -> schema.org/maximumOccupancy
  • accommodationSize seems like an odd name for square footage. Is there a more apt name? If this stays a child of Product, can we have a more generic "size" or "quantity" property?
  • What is the difference between schema.org/feature and schema.org/includedFeature?
  • Can we combine petsAllowed and smokingAllowed under a broader enumeration instead of having booleans?
  • Why is mealService different than other included or available features?
  • Why not add schema.org/bed to schema.org/Accommodation instead of specific subtypes?
  • Can we reuse schema.org/hoursAvailable instead of introducing schema.org/availabilityTimes?
  • I am not sure I understand schema.org/starRating. Can we instead expand to have a "ratedBy" property on schema.org/Rating?
  • Can we create a larger physical access enumeration in place of "gated". For example, some hotels allow the public to buy day passes to the pool. Perhaps this combines with my earlier question about optionalFeature.

@vholland
Copy link
Contributor

One more question. How does this work with http://schema.org/Residence and its subtypes?

@vholland
Copy link
Contributor

My concerns are twofold. First, we are forcing physical spaces into a model that works for rentals, but starts to make modeling other things more difficult. Second, the new proposal should integrate with the existing schema to avoid conflicts and confusion.

To further the discussion, I have modified @mfhepp's proposal. (The complete list of changes is below.) to reflect the following:

  • http://schema.org/LodgingBusiness (an existing type) is for the larger business and a subtype of Place. One can rent an accommodation which is a part of the LodgingBusiness.
  • http://schema.org/Residence (an existing type) is for private residences and a subtype of Place. One may rent or buy a Residence as a whole.
  • A http://schema.org/SubStructure (new here) is for parts of a Residence or LodgingBusiness and is a Place. Room, CampingSite, and Suite are subtypes of SubStructure. Any thoughts on a better name than SubStructure?
  • An http://schema.org/Accommodation is a type of Product. One buys/rents an Accommodation.

As a result of moving these types around, the properties in the original proposal have been moved to either be on the physical place or the Accommodation as appropriate.

The complete list of changes from pull request #916 are:

  • Existing schema changes
    • Added ResidenceComplex
    • ApartmentComplex now a subtype of ResidenceComplex (was Residence)
    • GatedResidenceCommunity now a subtype of ResidenceComplex (was Residence)
    • Added Resort as a supertype for SkiResort
    • Campground now a subtype of LodgingBusiness (was CivicStructure)
    • Added numberOfRooms to Residence
    • Added numberOfBathrooms to Residence
    • Added numberOfBedrooms to Residence
    • Added sizeOrAmount to Product and Residence
    • Added entityRating to Organization, Place, Event, Service, CreativeWork, Product, Brand, and Offer.
    • Made Rating a subclass of CreativeWork.
  • Proposal changes
    • Removed Place as a supertype of Accommodation. To be useful, authors will need to specify the type of Place.
    • Removed House in favor of the existing SingleFamilyResidence
    • Moved Apartment to being a subtype of Residence
    • Removed CampingSite in favor of the existing Campground
    • Added a SubStructure type
    • Moved CampingPitch to being a subtype of SubStructure (was Accommodation)
    • Moved Room to being a subtype of SubStructure (was Accommodation)
    • Moved Suite to being a subtype of SubStructure (was Accommodation)
    • Removed numberOfRooms from Accommodation
    • Removed validFrom and validThrough from AccommodationFeature. These are already in OpeningHoursSpecification.
    • Removed availabilityTimes in favor of the existing hoursAvailable.
    • Removed mealService from LodgingBusiness in favor of Accommodation.
    • Changed AccommodationFeature to AccommodationFeatureSpecification.
    • Changed feature to accommodationFeature.
    • Changed includedFeature to includedAccommodationFeature.
    • Changed optionalFeature to optionalAccommodationFeature.
    • Made optionalAccommodationFeature and includedAccommodationFeature sub-properties of accommodationFeature.
    • Changed permittedUsage to permittedAccommodationUsage.
    • Removed petsAllowed in favor of permittedAccommodationUsage.
    • Removed smokingAllowed in favor of permittedAccommodationUsage.
    • Changed occupancyAdults to maximumOccupancyOfAdults.
    • Removed maximumAdultOccupancy from LodgingBusiness.
    • Changed occupancyMinors to maximumOccupancyOfMinors.
    • Removed accommodationSize in favor of sizeOrAmount.
    • Changed occcupancy to maximumOccupancy.
    • Removed startRating in favor of entityRating.
    • Removed LodgingBusiness from the domain for audience.
    • Removed LodgingBusiness from the domain for availableLanguage.
    • Removed LodgingBusiness from the domain for category.
    • Changed gated to physicalAccessRestrictions with a range of Text.
    • Changed bed to bedInAccommodation.
    • Changed domain of bedInAccommodation to Accommodation.

@mfhepp
Copy link
Contributor Author

mfhepp commented Mar 16, 2016

I have reviewed @vholland 's proposal and suggest we should stick with our approach and address the individual concerns / aspects individually. The modified PR in #1011 creates new inconsistencies, IMO.

Here are my first comments, replying to the first part of comments by Vicki:

  • Can we avoid adding Accommodation as a child of both Place and Product? It would seem better to have authors use multiple types as appropriate. Otherwise, almost any type should be co-typed as a Product.

MH: An alternative solution is to include Accommodation to the domain of itemOffered and typeOfGood.
Action: include Accommodation to the domain of itemOffered and typeOfGood, update hotels.html and illustration.

  • There are many generic names, which may haunt us in the future. The following are suggested changes:
    • schema.org/AccommodationFeature -> schema.org/AccommodationFeatureSpecification
      MH: I think this is a stretch. While I see the need for unique names, we must also aim for catchy ones. AccommodationFeatureSpecification is like "PlaceOfSalesAndServiceProvisioning" in the old GoodRelations days.
      Action: Keep name
    • schema.org/feature -> schema.org/accommodationFeature
    • schema.org/includedFeature -> schema.org/includedAccommodationFeature
    • schema.org/optionalFeature -> schema.org/optionalAccommodationFeature
      MH: We could use schema:amenity, schema:includedAmenity, schema:optionalAmenity.
      Action: Change names and examples and hotels.html
    • schema.org/permittedUsage -> schema.org/permittedAccommodationUsage
      MH: I would rather introduce permittedUsage for Accommodation now and plan for the reuse by expanding the domain to new types later on (e.g. rental cars may also have such information).
      Action: Update text for schema:permittedUsage to a more generic one.
    • schema.org/bed -> schema.org/accommodationIncludesBed
      MH: I would not change this and rather plan for a later reuse of the property (e.g. for mobile homes).
      Action: Update text for schema:bed to a more generic one
    • schema.org/occupancy -> schema.org/maximumOccupancy
      MH: No, occupancy links to a QuantitativeValue. Whether it is a point value (exactly one person), a min or a max value depends on the QuantitativeValue. Furthermore, there might be accommodation that also indicate a minimum occupancy (in particular if the room is charged per person). AirBnB also has minimum occupancy information.
      Action: Keep it as it is.
  • accommodationSize seems like an odd name for square footage. Is there a more apt name? If this stays a child of Product, can we have a more generic "size" or "quantity" property?
    MH: The unit can be varying, e.g. sqft, sqm, etc. "room size" is a very popular term for this feature, but we want to be able to apply it to camping pitches, tents, house boats, etc., so I think accommodationSize is good enough. BTW, booking.com uses "room size".
    Action: Keep
  • What is the difference between schema.org/feature and schema.org/includedFeature?
    MH: A schema:feature (or new: schema:amenity) is a room or hotel feature, but no info is given on whether its usage is included in the room rate or not. schema:includedFeature/includedAmenity is a room or hotel feature that is free to use if you pay the room rate. A schema:optionalFeature/optionalAmenity is a room or hotel feature that is available for extra pay.
  • Can we combine petsAllowed and smokingAllowed under a broader enumeration instead of having booleans?
    MH: We could, but I think these are among the most basic features and also likely useful for later reuse. A pet owner needs a room with pets allowed, a non-smoker might want a non-smoking room. Both are IMO pretty much boolean conditions. We could include Text in the range of schema:petsAllowed.
    We could make them subproperties of permittedUsage, but IMO that would be wrong, because in both cases we do not only care about what WE are allowed to do, but also what previous users were doing in the room.
    Action: Include Text in the range of schema:petsAllowed.
  • Why is mealService different than other included or available features?
    MH; Because we want a basic mechanism for indicating whether breakfast, half-board or full-board are included. Again, I think those are very essential features that justify special treatment.
  • Why not add schema.org/bed to schema.org/Accommodation instead of specific subtypes?
    MH: Because a meeting room and a camping pitch do not have beds.
  • Can we reuse schema.org/hoursAvailable instead of introducing schema.org/availabilityTimes?
    MH: You are right, thanks for the catch!
    Action: Remove property, update hotels.html and examples.
  • I am not sure I understand schema.org/starRating. Can we instead expand to have a "ratedBy" property on schema.org/Rating?
    MH: No, a hotel star rating is really not a "review rating" in the sense of Rating, but are classifications that follow a standard evaluation procedure by an organization with special authority. See https://en.wikipedia.org/wiki/Hotel_rating.
    Action: Keep as it is.
  • Can we create a larger physical access enumeration in place of "gated". For example, some hotels allow the public to buy day passes to the pool. Perhaps this combines with my earlier question about optionalFeature.
    MH: If you want we can drop this property.
    Action: Remove property and check examples.
  • What is the difference between schema.org/CampSite and the existing schema.org/Campground?
    MH: Thanks for spotting this! I suggest that we merge http://sdo-hotels.appspot.com/CampingSite and the existing schema.org/Campground, taking the better new text and subclass relationship to LodgingBusiness.
    Action: Merge http://sdo-hotels.appspot.com/CampingSite and the existing schema.org/Campground; check hotels,html, check examples.

@mfhepp
Copy link
Contributor Author

mfhepp commented Mar 16, 2016

And here is my feedback to the second round of suggestions, as implemented in PR #1011:

  • My concerns are twofold. First, we are forcing physical spaces into a model that works for rentals, but starts to make modeling other things more difficult. Second, the new proposal should integrate with the existing schema to avoid conflicts and confusion.
    MH: I think that the changes proposed above will address this and reuse existing properties.
  • http://schema.org/LodgingBusiness (an existing type) is for the larger business and a subtype of Place. ** One can rent an accommodation which is a part of the LodgingBusiness.
    MH: I think this is properly reflected in our model.
  • http://schema.org/Residence (an existing type) is for private residences and a subtype of Place. One may rent or buy a Residence as a whole.
    MH: I think the current Residence type is a role notion in the sense that the place is used as a Residence. I would not integrate the two. See also https://en.wikipedia.org/wiki/Residence: "A residence is an establishment where it was originally or currently being used by a host as their main place of dwelling or home."
  • A http://schema.org/SubStructure (new here) is for parts of a Residence or LodgingBusiness and is a Place. Room, CampingSite, and Suite are subtypes of SubStructure. Any thoughts on a better name than SubStructure?
    MH: I think this adds more confusion than clarification.
  • An http://schema.org/Accommodation is a type of Product. One buys/rents an Accommodation.
    MH: As suggested above, we drop the supertype and instead expand the domain of itemOffered and typeOfGood.

As a result of moving these types around, the properties in the original proposal have been moved to either be on the physical place or the Accommodation as appropriate.

For the other changes, I suggest to address them in the context of a separate real estate extension proposal. The risk of future conflicts are pretty low, IMO.

One more thing: We should add a schema:businessFunction to all rental examples.

  • Removed validFrom and validThrough from AccommodationFeature. These are already in OpeningHoursSpecification.
    MH: There is a difference between the seasonal availability of the feature (sauna in winter) vs. the validity of the opening hours. If the later expire, you simply do not have current opening hours information. If the validThrough on the feature expires, the feature is unavailable in that period.
    You can have different opening hours for different seasons.

I hope you can accept these arguments. Please indicate and we can then quickly update PR #916 accordingly.

@danbri
Copy link
Contributor

danbri commented Mar 18, 2016

@vholland @mfhepp - much as I would love to merge this work in for immediate release, it seems you are in mid-discussion. Any chance you could hop into a Skype/Hangout/phone call in next few days to try to resolve these differences?

I am also now convinced that we should move to clockwork-based monthly releases, so the fear of "missing the release and waiting 2-3+ months" goes away. I'd like to publish a release in final days of March, and another at end of April, etc...

/cc @rvguha @shankarnat @scor @pmika @chaals

@danbri
Copy link
Contributor

danbri commented Mar 18, 2016

Re star rating awards, note that we already have

http://schema.org/award

It is currently text valued but is close to the target meaning

@vholland
Copy link
Contributor

I agree that this is not ready for the next release.

I will see if I can sync with @mfhepp offline, but would value other opinions as well.

@mfhepp
Copy link
Contributor Author

mfhepp commented Mar 18, 2016

Hi Vicki,

yes, let's try to sync up via Skype early next week. By then, we will also have the new pull request of mine that incorporates all consensual proposals.

As for the general model:

  1. As said in the thread, I am fine to drop the subclassOf relationship to Product for all accommodations like HotelRoom, CampingPitch, etc. and instead expand the domain of itemOffered and the range of typeOfProduct. Most of the properties of Product do not fit for hotel rooms etc.

But I strongly suggest to keep them as places, because they cleary "have a somewhat fixed, physical extension."

  1. The Accommodation class is IMO much more suited to group any place that can accommodate people than Residence. Residence has a very special meaning and does not fit as a supertype for meeting rooms, house boats, igloos, etc.
  2. The rest of my proposal clearly fits the existing type hierarchy of schema.org with http://schema.org/LodgingBusiness as the main type for the local business.

Currently, we already have

• BedAndBreakfast
• Hostel
• Hotel
• Motel

My proposal just adds

• CampingSite
• Resort

CampingSite is, as you pointed out, redundant and can be removed.

So my proposal keeps the existing structure for hotels in schema.org unchanged.

  1. I strongly advise to leave out any new element that is for real estate scenarios and tackle that in a separate proposal, as long as the hotels extension does not create inconsistencies that will backfire in real estate scenarios.

My proposal just adds schema:Accommodation and the following five subtypes:

More specific Types
• Apartment
• CampingPitch
• House
• Room
• Suite

Most of them might also be useful for real estate, but the proposed pattern does not at all rule out this additional use, because we only have Place -> Accommodation as a supertype, like so:

Thing > Place > Accommodation > House

It is clear that one important difference between a Hotel, Motel, Resort etc. is that the former are a business and a place (as in the current schema.org model), while the subtypes of Accommodation and likely additional types for real estate are just subtypes of Place or Accommodation.

"First, we are forcing physical spaces into a model that works for rentals, but starts to make modeling other things more difficult."

By removing the Product supertype as agreed, this conflict should go away.

"Second, the new proposal should integrate with the existing schema to avoid conflicts and confusion."

Actually, I would argue that our proposal fits the existing structure of schema.org much stricter that your updated one. I think the thing we should discuss is whether we introduce Accommodation as a supertype for all places that can accommodate human beings, or whether we reuse Residence for this purpose.

Martin


martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 18 Mar 2016, at 16:39, vholland notifications@github.com wrote:

I agree that this is not ready for the next release.

I will see if I can sync with @mfhepp offline, but would value other opinions as well.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@danbri
Copy link
Contributor

danbri commented Mar 23, 2016

For anyone following along: Martin, Vicki and I had a call about this yesterday, to try to work through some of the disagreements. I think we made some reasonable progress. Martin will take the next step summarizing the rough consensus into a revised pull request (or failing that, textual note).

@mfhepp
Copy link
Contributor Author

mfhepp commented Mar 23, 2016

Here is the list of agreed changes following the concall with @danbri and @vholland:

They are not yet implemented in the pull request but will shortly.

  • remove occupancyMinor and occupancyAdult and put this into a future hotels extension
  • remove mealService property and replace it by a pattern using a MealService type and TypeAndQuantityNode example
  • narrow domain of occupancy to HotelRoom, Suite, MeetingRoom
  • remove optionalFeature and includedfeature and put this into a future hotels extension
  • narrow down domain of bed property to HotelRoom and Suite so that houses etc. do not have this property
  • narrow down domain of numberOfRooms to House, Apartment, Suite and SingleFamilyHome (to avoid e.g. Rooms to have a number of rooms property)
  • remove roomNumber property
  • rename accommodationSize to floorSize
  • remove permittedUsage and put this into a future hotels extension
  • change range for petsAllowed to Boolean OR Text
  • move SingeFamilyResidence type to be a subtype of House instead of Residence
  • remove subClassOf from Product to Accommodation; include Accommodation to the domain of itemOffered and typeOfGood, update hotels.html and illustration.
  • update text for schema:permittedUsage to a more generic one.
  • update text for schema:bed to a more generic one
  • reuse schema.org/hoursAvailable instead of introducing schema.org/availabilityTimes; Remove property, update hotels.html and examples.
  • replace starRating by new property that links to schema:Rating and expand range of ratingValue to includeNumber
  • remove schema:gated property (maybe reserve it for future real estate extension)
  • merge http://sdo-hotels.appspot.com/CampingSite and the existing schema.org/Campground
  • add a schema:businessFunction to all rental examples.
  • SDTT: Maybe issue warning that if no businessFunction is indicated, Sell is assumed.
  • update all examples
  • update hotels.html and illustration accordingly

@danbri
Copy link
Contributor

danbri commented Apr 4, 2016

@mfhepp - would it make sense to ship sdo-deimos as v2.3 and continue with this for the next release?

I would like to get our release cycle back down to 6 weeks or less. Longer cycles end up in a self-fulfilling dynamic where we delay to include things (like this) and the "risk of missing the window" feels bigger because of concern that the next release will be similarly delayed. How close are we here to getting #915 closed and fully implemented?

@mfhepp
Copy link
Contributor Author

mfhepp commented Apr 4, 2016

I will update the pull request according to our agreement in the next 48 hours, so the issue should be ready for shipment in 2.3.
Martin

On 04 Apr 2016, at 19:11, Dan Brickley notifications@github.com wrote:

@mfhepp - would it make sense to ship sdo-deimos as v2.3 and continue with this for the next release?

I would like to get our release cycle back down to 6 weeks or less. Longer cycles end up in a self-fulfilling dynamic where we delay to include things (like this) and the "risk of missing the window" feels bigger because of concern that the next release will be similarly delayed. How close are we here to getting #915 closed and fully implemented?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@danbri
Copy link
Contributor

danbri commented Apr 6, 2016

How's it going, @mfhepp ?

@mfhepp
Copy link
Contributor Author

mfhepp commented Apr 6, 2016

asap ;-)

@danbri
Copy link
Contributor

danbri commented Apr 11, 2016

(Wanders past, waves...)

@jaygray0919
Copy link

(Don't forget room service and the minibar ...)

@rvguha
Copy link
Contributor

rvguha commented Apr 11, 2016

On Mon, Feb 22, 2016 at 11:55 AM, vholland <notifications@github.com
https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=notifications@github.com

wrote:

The conversation has spanned a few different issues, so I am not sure
where best to update, but my outstanding questions/comments are:

  • Can we avoid adding Accommodation as a child of both Place and
    Product? It would seem better to have authors use multiple types as
    appropriate. Otherwise, almost any type should be co-typed as a Product.

At a high level I agree, but in practical terms, we will have to deal with
the problem that a large number of webmasters might forgot to do so.

There are many generic names, which may haunt us in the future. The
following are suggested changes:

  • schema.org/AccommodationFeature ->
    schema.org/AccommodationFeatureSpecification
    • schema.org/feature -> schema.org/accommodationFeature
    • schema.org/includedFeature ->
      schema.org/includedAccommodationFeature
    • schema.org/optionalFeature ->
      schema.org/optionalAccommodationFeature
    • schema.org/permittedUsage ->
      schema.org/permittedAccommodationUsage
    • schema.org/bed -> schema.org/accommodationIncludesBed
    • schema.org/occupancy -> schema.org/maximumOccupancy

yes to all of these.

accommodationSize seems like an odd name for square footage. Is there
a more apt name? If this stays a child of Product, can we have a more
generic "size" or "quantity" property?

  • What is the difference between schema.org/feature and
    schema.org/includedFeature?
  • Can we combine petsAllowed and smokingAllowed under a broader
    enumeration instead of having booleans?
  • Why is mealService different than other included or available
    features?
  • Why not add schema.org/bed to schema.org/Accommodation instead of
    specific subtypes?
  • Can we reuse schema.org/hoursAvailable instead of introducing
    schema.org/availabilityTimes?
  • I am not sure I understand schema.org/starRating. Can we instead
    expand to have a "ratedBy" property on schema.org/Rating?
  • Can we create a larger physical access enumeration in place of
    "gated". For example, some hotels allow the public to buy day passes to the
    pool. Perhaps this combines with my earlier question about optionalFeature.


Reply to this email directly or view it on GitHub
#915 (comment)
.

@mfhepp
Copy link
Contributor Author

mfhepp commented Apr 11, 2016

Please note that Dan, Vicki and I already agreed upon a solution for the ongoing discussion (see above - my message #915 (comment)).

This is not yet implemented in the PR but I will craft this very quickly, ready for 2.3

@danbri
Copy link
Contributor

danbri commented Apr 21, 2016

Talking with @mfhepp we're not going to rush this out for the 3.0 (previously 2.3, but it got upgraded:) release currently under review. It is better to take the time to implement it carefully, given the subtlety of the issues and the ease of getting something wrong.

@danbri danbri added status:implementing status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area. type:tricky problem Hard problems, including modeling / vocabulary and infrastructural aspects (eg fiction, probability) labels May 18, 2016
@danbri
Copy link
Contributor

danbri commented May 18, 2016

@mfhepp do you want me to take a pass at the most obvious changes in #915 (comment) ? I could implement it into pending.webschemas.org for collaboration...

@danbri
Copy link
Contributor

danbri commented Jun 14, 2016

@mfhepp and I just talked about this, he is working on it this week and will base his work on 1.) the current 'master' branch (sdo-deimos and some post-publication quick fixes) 2.) the agreement noted above from discussion with @vholland .

@danbri
Copy link
Contributor

danbri commented Aug 10, 2016

@danbri danbri closed this as completed Aug 10, 2016
@danbri
Copy link
Contributor

danbri commented Aug 10, 2016

@thadguidry
Copy link
Contributor

@danbri @vholland @mfhepp Did we agree to Remove or Keep the numberOfRooms on Accommodation AND House ?

I see some kinda mixup in the proposal and the Git pull itself for numberOfRooms it seems. This was supposed to happen from the proposal...
'Removed numberOfRooms from Accommodation'

But looking at House and Accomodation...they both have the property numberOfRooms. Do we care ?

@danbri
Copy link
Contributor

danbri commented Aug 11, 2016

@thadguidry re numberOfRooms, I was persuaded by @brewerdigital's argument earlier this week that @mfhepp 's related edit may have been a failed attempt to add another type association to the property. I attached it to Accommodation (instead of Hotel) but this may not have been as intended. If so we can adjust it ASAP. I had to make a last minute judgment call and it's quite possible it wasn't ideal - I remember some discussion about room counting different in real estate vs hotel situations (i.e. whether you count the bathroom).

@mfhepp
Copy link
Contributor Author

mfhepp commented Aug 23, 2016

I think the story was that the property had initially been attached to Accommodation, but this created the inconsistency that e.g. HotelRooms can themselves have this property, so we ended up listing a few relevant types manually. Feel free to fix the domain of this property.

@inetbiz
Copy link

inetbiz commented Sep 18, 2020

https://schema.org/CampingPitch needs https://schema.org/occupancy In the Caravan / RV world, lots are priced at per max occupancy of around 2 adults. This is to account for the water/sewage and sometimes electrical usage for that offering. @mfhepp

@RichardWallis
Copy link
Contributor

Would occupancy be better placed on Accommodation?

@eliaskaerle
Copy link

eliaskaerle commented Sep 18, 2020 via email

@inetbiz
Copy link

inetbiz commented Sep 18, 2020

Would occupancy be better placed on Accommodation?

A campingPitch, even if just a tent space rented from an RV park puts limits on the occupancy. Because the rate is calculated on COGS. The water, power and sewage all costs money. Couldn't have 12 people in a camping lot based on 2 adult price. Even national parks that offer camping / RV place limits on maximum occupancy and charge if you go over that limit. I looked at the allowed places I could put occupancy. CampingPitch wasn't one.
image

@EricAxel
Copy link
Contributor

EricAxel commented Sep 18, 2020 via email

@inetbiz
Copy link

inetbiz commented Sep 18, 2020

I do also @EricAxel it would make it easier for my purposes.

@jeannieh
Copy link

jeannieh commented Sep 18, 2020 via email

@RichardWallis
Copy link
Contributor

Reopening issue to capture the occupancy discussion

@RichardWallis RichardWallis reopened this Sep 18, 2020
@jeannieh
Copy link

jeannieh commented Sep 18, 2020 via email

@github-actions
Copy link

This issue is being tagged as Stale due to inactivity.

@github-actions github-actions bot added the no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!). label Nov 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!). schema.org vocab General top level tag for issues on the vocabulary status:work expected We are likely to, or would like to, or probably should try, ... to do something in this area. type:tricky problem Hard problems, including modeling / vocabulary and infrastructural aspects (eg fiction, probability)
Projects
None yet
Development

No branches or pull requests