-
Notifications
You must be signed in to change notification settings - Fork 835
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
The serviceArea property should have a range of Place not AdministrativeArea #411
Comments
I am fine with this, but we should add a note that recommends the more granular offer -> eligibleRegion / availableAtOrFrom / delivery options patterns. |
If I might ask, @mfhepp how about merging Personally I find it hard to tell when to use IMHO the difference between both properties should either be explained better - for folks like myself ;) - or we should consider merging them into Or am I over-simplifying it by suggesting this? |
Hmm. There is a difference, but I see the potential for making serviceArea a superproperty of both (but with a different name). eligibleRegion indicates the area to which you will be willing to deliver (for physical things) or in which the buying party resides (for services and other immaterial goods like software, music, ... availableAtOr from links to a point of sales from which you can obtain a good or service, e.g. a location from which you can rent a car, pick up a good, receive a haircut, etc. Historically, the range of eligibleRegion was an ISO 3166 code, and that of availableAtOrFrom was a place. If we align the range, we could think about aligning the properties. |
But also note that eligibleRegion is also used on gr:License and schema:DeliveryChargeSpecification. We need to double check dependencies and will likely break old data or applications. Still worth investigating. |
Ok, let's attend to eligibleRegion and availableAtOrFrom separately. The "low hanging fruit" here is to fix the range of serviceArea, which is currently inappropriately tight. I will add Place, as well as GeoShape (since some service areas aren't name-able places, so it is clunky to force an intermediate Place/geo structure here). |
ok see http://sdo-phobos.appspot.com/serviceArea "Values expected to be one of these types: GeoShape, Place. |
+1 |
In fixing this I discovered another cleanup issue: we also had areaServed on ContactPoint. I have marked it supersededBy serviceArea and added ContactPoint as a type for serviceAre - see #803 for details. |
+1 |
1 similar comment
+1 |
Just posted to #803: "@rvguha just made the sensible point that it would be better (c.f. #803) to have a property name that can't be easily mistaken for a type name. Therefore I propose we flip the supersededBy relationship around, and adopt areaServed as a (slightly) less-nouny preferred name. Unless anyone disagrees I'll update the draft site accordingly, with areaServed taking on the work now done by serviceArea. Currently we have both of these properties in parallel unrelated use, so one needs to be picked - I just think now I picked the wrong one." Consequence here is that we continue as above, but consolidate around areaServed instead of serviceArea. |
I have implemented the flip of serviceArea to areaServed (i.e. reversed the supersededBy relationship). I have also made a pass through, declaring both eligibleRegion and availableAtOrFrom as sub-properties of the common broader areaServed property. The areaServed property list of associated types (domain and range) are amended accordingly. The definition is simply "The geographic area where a service or offered item is provided.". @mfhepp 's account of the three properties' subtle differences I think justified their continuing distinct existence (and we could improve their descriptions to match). However it was painful that they were not even previous related to each other. I think having eligibleRegion and availableAtOrFrom as sub-properties makes sense. Note also that we have ineligibleRegion nearby, which remains untouched. |
…Region, availableAtOrFrom; supersedes areaServed. This cleanup gives named relationships to these 4 very very similar-sounding properties. The associated types on areaServed now include all those used on its sub-properties.
Looks ok to me. BTW, is there a way in the code to mark "associatedProperty" so that looking at eligibleRegion would lead you to ineligibleRegion? |
@chaals - I was thinking just the same. For now (like per-type deprecations) we have to write it out in the entity-escaped HTML description, which is both tedious and easy. In a way the types themselves are the real grouping construct for related properties, but whenever a property is usable on several types the assocation to related properties does become rather indirect. Let's add something. |
+1 |
@chaals - I've cross referenced eligibleRegion and ineligibleRegion as suggested - thanks! |
👍 |
Fixed in http://schema.org/docs/releases.html#v2.2 - thanks all |
The serviceArea property can be used for Places that are not AdministrativeAreas.
The text was updated successfully, but these errors were encountered: