Rename feature and AccommodationFeature to preserve namespace and extend domain

[vholland]

http://webschemas.org/feature was introduced as part of the hotels proposal in pull request #1224. Given that schema.org exists in a single namespace and "feature" could be applied to many things, we should consider renaming the property.

This got me to thinking that the style of feature listed for hotels may apply to other types of businesses. For example, a coffee shop may want to specify that it has WiFi.

I propose:

• Renaming "feature" to "locationFeature".
• Renaming "AccommodationFeature" to LocationFeatureSpecification.

[mfhepp]

Vicki:
I would have no objections if you want to rename the property to locationFeature or placeFeature. Note that we did not name it accommodationFeature in order to avoid having the same name for property and type.

Same for the type, but I think that PlaceFeature is better.

Also note that you can always use the plain additionalProperty property; the main reason for feature / AccommodationFeature is that the features can have opening / availability times, which is not a generic property of a PropertyValue.

If you think that these rather late name changes quite some time after our conference call are mission-critical, I kindly ask you to implement them by means of a pull request, and to make sure they are also reflected in all parts of the documentation (namely examples and hotels.html). Thank you!

[danbri]

@mfhepp - with respect these "late name changes" suggestions are not so late; @vholland raised the matter back in December last year. Re-reading the dialogue from #915 to figure out where we are and how we got here...

• @mfhepp responded "will reply in detail asap" (Dec 14 2015)
• @vholland reiterated that proposal (amongst others), and implemented it, on February 29th 2016.
• @mfhepp detailed response of March 16th 2016: "I have reviewed @vholland 's proposal and suggest we should stick with our approach and address the individual concerns / aspects individually. ".
  • rejected proposal of AccommodationFeature -> schema.org/AccommodationFeatureSpecification
  • counter-suggestion of *amenity for schema.org/feature -> schema.org/accommodationFeature
  • @mfhepp: "We could use schema:amenity, schema:includedAmenity, schema:optionalAmenity. Action: Change names and examples and hotels.html"

All this was the background to a Skype chat that @mfhepp, @vholland and myself had on Mar 23. Thanks to Martin for his detailed notes which did note "remove optionalFeature and includedfeature and put this into a future hotels extension" but didn't cover any conclusion on the name changes discussed here. Things then went quiet April 4th - June 23rd, before our latest and hopefully final flurry of collaboration based on Martin's implementation of the notes from the call with Vicki and myself.

If anything is clear, it is that everyone is pretty busy and juggling multiple commitments, and that detailed pieces of a large design discussion are difficult to bear in mind after substantial gaps in the discussion.

Let's just figure out what to do.

For the property proposed currently as 'feature', suggestions are:

• locationFeature
• placeFeature
• amenityFeature

For the type proposed currently as 'AccommodationFeature', suggestions are:

• LocationFeatureSpecification
• PlaceFeature

As background, here is a list of terms with 'specification' in their name.

My (mild) preference would be the combination of the property amenityFeature and a type LocationFeatureSpecification. Our immediate emphasis does seem to be around (relatively tangible) amenities, and places have many other characteristics that might be relevant in other contexts. In an accommodation context (and likely later for real estate too) we will be concerned with those features that are amenities.

My strong preference is that we pick something and move along.

/cc @chaals @shankarnat @tmarshbing @scor @vholland @rvguha

[danbri]

Note: I will proceed with implementing on amenityFeature + LocationFeatureSpecification for sake of progressing this asap, but I am open to a difference consensus emerging here, and will put in the re-editing time if further changes are needed.

[mfhepp]

Dan:
I can live with either choice with a slight preference for placeFeature and PlaceFeatureSpecification.

But as you say, getting this going should be our priority.

Martin

[danbri]

I've made a pass through schema.rdfa, sdo-hotels.txt examples and docs/hotels.html for these and related edits. I think we can get away without updating the image in http://webschemas.org/docs/hotels.html

Please take a look.

[danbri]

I've done my best to reflect rough consensus from this discussion into the release candidate that I have just proposed for release, https://lists.w3.org/Archives/Public/public-schemaorg/2016Jul/0015.html

[vholland]

@danbri Thanks for the update.

I don't care whether it is PlaceFeatureSpecification or LocationSpecificationFeature, but can we change the domain to LocalBusiness (instead of the more specific LodgingBusiness)?

[vholland]

It appears the update omitted http://schema.org/Residence and its subtypes other than http://schema.org/SingleFamilyResidence as mentioned back in February.

We could squeeze http://schema.org/Residence under Accommodation, but apartment complexes and gated communities aren't really lodging businesses. I'm not sure how to proceed with those.

[danbri]

@vholland thanks, duly noted in #1212 (comment)

I won't edit the review candidate as it has been circulated, now but the domain expansion to LocalBusiness sounds ok. It could also be on Place, if amenity is ~ "a desirable or useful feature or facility of a building or place.". This seems something it would be reasonable to fix trivially before 3.1 goes out.

Also not sure how to proceed with Residence. Is this something we can iterate on in a later update?

[danbri]

Residence -> #1270

[danbri]

I think we're done here. Closing.

[danbri]

Thing > Intangible > Enumeration > QualitativeValue > BedType

ok, reviewing our releases.html document, we didn't mention the addition of BedType yet. It has been up at http://pending.schema.org/BedType since the middle of last year - any feedback on it? Is the design reasonable, is it used? /cc @vholland

[thadguidry]

@danbri using as designed in pending. shhh :)

[vholland]

I remember the original discussion included the fact that bed types are not universal. In particular, the US has oddities like "California King". The implementation in pending was the best way we could normalize bed types while also acknowledging that there is not a single set of enumerative values.

In summary, I think it's the best we are going to get on this.

[danbri]

Thanks @vholland - yes, not to be confused with https://en.wikipedia.org/wiki/California_kingsnake . The main thing that gave me pause for thought was the location in the hierarchy. The modeling is pretty meta and hard to articulate in English. Maybe "BedType is an Enumeration type, whose members would be specific kinds of beds; and because these are 'predefined value for a product characteristic' it is a subtype of QualitativeValue (which itself is a subtype of Enumeration)".

@thadguidry - that's pretty much what pending is for. We can try things out and verify - however informally - that they are roughly fit for purpose. Or tweak definitions based on that experience, or give up the idea as a bad idea, ...

[thadguidry]

@danbri you must have forgot who I am. :) I know what pending is for, I've been using pending since we gave it birth. My apps already have 4th grade understanding of pending unlike other tools which shall go unnamed. (SDTT !) :)

Oh and at 6'4" me and my California King are NOT an oddity :)

[danbri]

@thadguidry :) I know you know, but the "shhh" threw me off the trail!

[danbri]

Looking again at http://pending.schema.org/BedType

In summary, I think it's the best we are going to get on this.

I think @vholland was right. As a tiny improvement I think we should just move this to core with no great fuss, decluttering Pending is a good thing.

[rvguha]

I strongly agree with Vicki. btw, we have had this for a while and to my knowledge, this hasn't been used in any application ...

…

On Tue, Jul 26, 2016 at 12:06 PM Martin Hepp ***@***.***> wrote: Vicki: I would have no objections if you want to rename the property to locationFeature or placeFeature. Note that we did not name it accommodationFeature in order to avoid having the same name for property and type. Same for the type, but I think that PlaceFeature is better. Also note that you can always use the plain additionalProperty property; the main reason for feature / AccommodationFeature is that the features can have opening / availability times, which is not a generic property of a PropertyValue. If you think that these rather late name changes quite some time after our conference call are mission-critical, I kindly ask you to implement them by means of a pull request, and to make sure they are also reflected in all parts of the documentation (namely examples and hotels.html). Thank you! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1262 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCju4KBnf2lRs3SG97Cg353spQlnJks5qZlq9gaJpZM4JVaUj> .

[RichardWallis]

Implemented in release 3.5