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

Rename feature and AccommodationFeature to preserve namespace and extend domain #1262

Closed
vholland opened this Issue Jul 26, 2016 · 17 comments

Comments

Projects
None yet
4 participants
@vholland
Contributor

vholland commented Jul 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Jul 26, 2016

Contributor

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!

Contributor

mfhepp commented Jul 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 28, 2016

Contributor

@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

Contributor

danbri commented Jul 28, 2016

@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 danbri self-assigned this Jul 28, 2016

danbri added a commit that referenced this issue Jul 28, 2016

Removed BedType per #1263 but moving to pending.schema.org.
Also amended a mention of 'feature property' to say 'amenityFeature',
although this issue is not completely closed yet (#1262).
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 28, 2016

Contributor

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.

Contributor

danbri commented Jul 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Jul 28, 2016

Contributor

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

Contributor

mfhepp commented Jul 28, 2016

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 added a commit that referenced this issue Jul 28, 2016

danbri added a commit that referenced this issue Jul 28, 2016

danbri added a commit that referenced this issue Jul 28, 2016

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 28, 2016

Contributor

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.

Contributor

danbri commented Jul 28, 2016

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 added a commit that referenced this issue Jul 29, 2016

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 29, 2016

Contributor

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

Contributor

danbri commented Jul 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jul 29, 2016

Contributor

@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)?

Contributor

vholland commented Jul 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jul 29, 2016

Contributor

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.

Contributor

vholland commented Jul 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 29, 2016

Contributor

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

Contributor

danbri commented Jul 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 1, 2016

Contributor

Residence -> #1270

Contributor

danbri commented Aug 1, 2016

Residence -> #1270

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 1, 2016

Contributor

I think we're done here. Closing.

Contributor

danbri commented Aug 1, 2016

I think we're done here. Closing.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 1, 2017

Contributor

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

Contributor

danbri commented Mar 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Mar 2, 2017

@danbri using as designed in pending. shhh :)

thadguidry commented Mar 2, 2017

@danbri using as designed in pending. shhh :)

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Mar 2, 2017

Contributor

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.

Contributor

vholland commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 2, 2017

Contributor

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, ...

Contributor

danbri commented Mar 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Mar 2, 2017

@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 :)

thadguidry commented Mar 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 2, 2017

Contributor

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

Contributor

danbri commented Mar 2, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment