Changing the range of contactType & contactOption to Enumeration - was: What are those enumerations after the breadcrumb's :: called?

From: Jarno van Driel <jarnovandriel@gmail.com>
Date: 2015-01-17 13:30 GMT+01:00

> "Hope this helps"



> You have no idea how much that helped Dan. After sleeping on it, it now
> makes total sense to me. So, thanks! (you too Simon, and of course Gregg
> Kellogg as well, for making me raise my eyebrows about a month ago)


> "your a "happening" dude for asking these questions and learning"


Shucks, you're making me blush.   :-)   I'm happy my curiosity is well
> received and I hope to return this generosity by passing your remarks on to
> others.
>

> "Let us know if you see some enumerations that probably should be made"



> Well, since you mentioned it, I think there might be some which probably
> should be added, depending on whether or not all the sponsors can live with
> adding values Google suggests for schema.org/contactType on
> http://bit.ly/1BHxFBS:
> "customer support"
> "technical support"
> "billing support"
> "bill payment"
> "sales"
> "reservations"
> "credit card support"
> "emergency"
> "baggage tracking"
> "roadside assistance"
> "package tracking"


When I read these yesterday they immediately reminded me about Dan's
> comments in this thread:



> > "In general in schema.org, these enumerations serve are to give well known
> *values* for properties."


Now since Google recommends using these text values (as if they are
> Enumeration members), I predict it will only be a matter of time before
> they're 'well known'. So IMHO they seem to meet that criterion.
> Any thoughts?


> "I am sure there are some in the longer tail domains like Medicine, etc."



> I'll make sure to do so when I run into them. But I don't think that'll be
> any time soon. It's not all that often I get a chance to work on longer
> tail domains because they're, well, long tail. I'm already happy to get a
> chance to currently 'play' around in the Medicine field but alas it's not
> all too often that type of domain crosses my path.
> oh, and these for 'contactOption' as well:
> "TollFree"
> "HearingImpairedSupported"


oh, and these for 'contactOption' as well:
> "TollFree"
> "HearingImpairedSupported"


-----

After reading a related issue over on Github:
https://github.com/schemaorg/schemaorg/issues/238 I'd like to suggest to:

a] Change the range of 'contactType' & 'contactOption'
to ContactPointOption (Enumeration)
b] Add the following Enumeration members to ContactPointOption:
- BaggageTracking
- CustomerSupport (or CustomerService)
- Emergency
- PackageTracking
- Reservations
- RoadsideAssistance
- Sales
- TechnicalSupport
- VisualImpairedSupported
- VoiceImpairedSupported

ContactPointOption already contains:
- HearingImpairedSupported
- TolFree

"credit card support - this is typically just a reuse of customer support.
> Probably could skip it, and just use customer support."


I tend to agree with Thad on this, but since the following 'text' values
are already suggested in Google's documentation (http://bit.ly/1BHxFBS)
wouldn't it make sence to add the following Instances as well:
- BillingSupport
- BillPayment
- CreditCardSupport

Unless those are considered redundant, but in that might I suggest Google
changes it's documentation?

"So perhaps just "CommunicationsImpairedSupported" or
> "CommImpariedSupported" or "ImpairmentSupport". whatever works."


I also suggest adding VisualImpairedSupported, meaning schema.org would
cover Hearing, Visual and Voice. Maybe it's smart to approach
accessibility experts to find out what else might be interesting before we
start throwing more accessibility options into the mix?