Skip to main content

Replace physicallyAvailableAt with gr:availableAtOrFrom

Joinup Admin
Published on: 05/03/2013 Discussion

Following up on a comment from Owen, I was looking through the Good relations Ontology (widely used in eCommerce sites) and noticed it has a property gr:availableAtOrFrom defined: 

"This states that a particular gr:Offering is available at or from the given gr:Location (e.g. shop or branch)."

That looks pretty good to me. The range of gr:availableAtOrFrom is gr:Location which is defined as: "a point or area of interest from which a particular product or service is available, e.g. a store, a bus stop, a gas station, or a ticket booth."

The domain of gr:availableAtOrFrom is gr:Offering, the definition of which is a little convoluted: "An offering  represents the public, not necessarily binding, not necessarily exclusive, announcement by a gr:BusinessEntity to provide (or seek) a certain gr:BusinessFunction for a certain gr:ProductOrService to a specified target audience. An offering is specified by the type of product or service or bundle it refers to, what business function is being offered (sales, rental, ...), and a set of commercial properties. "

To me these definitions match ours closely enough that we can just re-use them and not define physicallyAvailableAt. Using gr:availableAtOrFrom implies that a Public Service is also a gr:Offering but that doesn't seem unreasonable??

Component

Documentation

Category

feature

Comments

Andrea PEREGO
Andrea PEREGO Thu, 28/03/2013 - 15:57

This seems to be a good solution in terms of interoperability, also considered the compatibility declared in GR with schema.org. Actually, the relevant terms in schema.org seem to be derived from the corresponding ones in GR - see, e.g., we also have schema:availableAtOrFrom property (see, e.g., the schema:Offer class).

I have however some concerns in terms of semantics - more precisely, about the semantic "scope" of the relevant terms in GR, schema.org, and CPSV:

  1. The notions of offer and availability, and location, as defined in GR and schema.org have as scope the business sector. So, I wonder whether they are broad enough to include the corresponding notions in the public sector. 
  2. About the notion of location, it would be important to ensure as much as possible the re-use of what defined in the Location Core Vocabulary, where the suggested term to denote a location is dcterms:Location. However, there is no explicit statement in GR and schema.org about the compatibility between gr:Location / schema:Place and dcterms:Location. Also, it's unclear whether gr:Location has a generic or specific scope. Its definition in GR suggests the latter, i.e., a place where a service, etc. is offered. On the other hand, gr:Location is also said to be equivalent to schema:Place, which is generic ("Entities that have a somewhat fixed, physical extension.") and it is thus similar to dcterms:Location

About point (1), I have a limited expertise in this area, so please consider my concern more as a question to more informed WG members.

About point (2), I wonder wether we can ask some feedback from Martin Hepp. In any case, for the reasons above, I strongly suggest dcterms:Location be specified in CPSV as the recommended range of property gr:availableAtOrFrom. This, of course, does not exclude the possibility of using also gr:Location / schema:Place. On the other hand, it would allow cross-sector and cross-border re-use of public service location information, at least inside the EU.

philarcher (not verified) Sun, 10/03/2013 - 18:19

The concerns raised by Andrea above are very much in line with the mood of the WG telecon on 6/3/13 wrt to the Good Relations implication of a service also being a commercial entity. Therefore it was decided not to use GR. The WG further resolved to:

Create a property of cpsv:hasChannel with a range of cpsv:Channel

Define foaf:homepage as a sub property of cpsv:hasChannel

Retain cpsv:physicallyLocatedAt and make that also a sub property of hasChannel

This leaves the door open to future properties such as 'ex:hasApp' etc.

The domain of hasChannel has been left as rdfs:Resource so that it can be used in other contexts, thus avoiding the inferences that prevented re-use of gr:availableAtOrFrom.