ContactPoint could be improved #238
I support reuse of existing specifications.
But sometimes details can be improved when they are reevaluated now. I for example doubt that a class hierarchy is optimal to encode gender as done in the vCard ontology (note to self: OpenGovLD/specs#23)
Hey,
Can someone elaborate on what this property actually means (i.e. at least an example value in the documentation https://schema.org/contactPoint )?
Yours hopefully
You can find an example on https://schema.org/ContactPoint. At this moment schema.org doesn't provide any examples on pages describing properties (it might in the future, there's been talk about it). Examples can be found on pages about types.
@jvandriel thanks for reply
I was a little hasty with this message as I've just discovered the following navigation sections - just trying to make sense of it now...:
- Values expected to be one of these types
- Used on these types
Apologies
@jvandriel Au contraire, mon frere! There are currently a number (16 in core, and 4 in extensions, as of master branch today) of examples in schema that are included on various property pages:
$ grep TYPES data/*examples.txt | grep "[ ,][a-z]" | wc -l
20
$ grep TYPES data/*examples.txt | grep "[ ,][a-z]"
data/examples.txt:TYPES: #eg-1 Person,PostalAddress,addressRegion,postalCode,address,streetAddress,telephone,email,url,addressLocality
data/examples.txt:TYPES: #eg2 Place,LocalBusiness, address, streetAddress, addressLocality, PostalAddress, telephone
data/examples.txt:TYPES: #eg-3 Painting,genre
data/examples.txt:TYPES: #eg-4 Restaurant,AggregateRating,FoodEstablishment,LocalBusiness,aggregateRating,ratingValue,reviewCount
data/examples.txt:TYPES: #eg-5 Place,GeoCoordinates,latitude,longitude,geo
data/examples.txt:TYPES: #eg-6 MediaObject,AudioObject,encodingFormat,contentUrl,description,duration
data/examples.txt:TYPES: #eg-7 Organization,PostalAddress,address,streetAddress,postalCode,addressLocality,faxNumber,telephone
data/examples.txt:TYPES: #eg-9 Event,Place,PostalAddress,AggregateOffer,location,startDate,address,offers,offerCount
data/examples.txt:TYPES: #eg-10 Product,AggregateRating,Offer,Review,Rating, price,aggregateRating,ratingValue,reviewCount,availability,InStock
data/examples.txt:TYPES: #eg-11 Product,AggregateRating,AggregateOffer,Offer,aggregateRating,image,offers
data/examples.txt:TYPES: #eg-12 WebPage,Book,AggregateRating,Offer,Review,CreativeWork,mainEntity
data/examples.txt:TYPES: #eg-13 Recipe,NutritionInformation, image,datePublished,prepTime,cookTime,recipeYield,recipeIngredient,calories,fatContent
data/examples.txt:TYPES: #eg-14 VideoObject,MusicGroup,MusicRecording,Event,video,interactionCount,InteractionCounter,duration,interactionStatistic,interactionType
data/examples.txt:TYPES: Book,CreativeWork,accessibilityFeature,accessibilityHazard,accessibilityControl,accessibilityAPI
data/examples.txt:TYPES: accessibilityFeature, accessibilityHazard, fileFormat
data/examples.txt:TYPES: fileFormat, accessibilityHazard, accessibilityFeature, accessibilityControl, accessibilityAPI
data/sdo-itemlist-examples.txt:TYPES: #itemlist-1 BreadcrumbList, ItemList, ListItem, itemListElement, item
data/sdo-mainEntity-examples.txt:TYPES: #mainEntity-1 mainEntity
data/sdo-mainEntity-examples.txt:TYPES: #mainEntity-2 mainEntityOfPage
data/sdo-periodical-examples.txt:TYPES: #bib-5 exampleOfWork, workExample
So getting a given example to be included in the schema:telephone doc page, and for other properties, is easily accomplished. And we should definitely do that!
Thanks for updating me @dbs, I had now idea talk had already been turned into action, somehow that fact had gone by me. :)
Yeah I had hoped to go through and add 100s, but didn't get there yet. It is a trivial, easy and super-useful fix if anyone cares to do a few more via pull request :)
We stumbled upon this issue as well. When you have a ContactPoint, the only way of giving it an address is by subclassing it to PostalAddress (which already seems a bit strange) but when you do that you can only make use of the structured form of addresses. Contrast this with the address property that can accept either Text or PostalAddress.
For a lot of internationalised address use cases, managing to obtain a properly structured address (and then somehow retrofitting that into the simple structure provided by schema.org) is a pretty tall proposition. Addresses are weird, not as much as calendars, but still. You do need the raw text escape hatch.
It would seem more sensible to us to have address be available on ContactPoint (in the same way that email or faxNumber are).
http://schema.org/ContactPoint
Migrating from http://www.w3.org/2011/webschema/track/issues/3
Somewhat vague as an issue, but also makes a reasonable point and worth noting:
"""Kurt Bollacker in http://lists.w3.org/Archives/Public/public-vocabs/2011Oct/0017.html raises some concerns