Inconsistency regarding Channel: hasContactPoint and hasCost

12/08/2019

The relations Channel:hasContactPoint and Channel:hasCost might look correct on first sight, but are not compatible with the definition of CPSV. CPSV defines foaf:homepage (range = "a Document") and cpsv:physicallyLocatedAt (range = dct:Location) as subtypes of cpsv:hasChannel. If we add the definitions from CPSV-AP, this poses problems:

 

ContactPoint (homepage)

Since homepages are defined as Channels by CPSV, this means that any homepage can get a ContactPoint. Although strange, one could argue that this makes sense. However, once multiple services are available from a single homepage, each having a different ContactPoint, it becomes impossible to link the service to its own contact point.

 

ContactPoint (physicallyLocatedAt)

Once a single location is available for multiple services, it becomes impossible to identify the proper contactPoint. Two examples:

- The location used defines a building (rather than a specific counter) where multiple government agencies are located. Because each agency adds their own contactpoint information to their location (the shared building), the information gets mixed up.

- The location used defines a counter where multiple services are availble. Each of these services has the same location, but a different phone number or email. Once again, information gets mixed up.

 

Cost (homepage/physicallyLocatedAt)

Defining a cost on a homepage or location does not make sense, it is the service that has a cost.

 

Component

Code

Category

bug

Comments

Fri, 11/11/2016 - 12:51

Thanks Dieter, that's very helpful. I admit I hadn't thought of those semantics. Thinking this through I propose:

Remove the hasContactPpint relation from Channel to Contact Point

Reverse the hasCost relation between Cost and Channel so that we have Public Service --> has Cost --> Cost --> if accessed through --> Channel

By the same token, I see that processing Time should not be a property of channel either (a homepage does not have a processing time). This was rather sloppy of me to be honest. Occam's Razor suggests we simply remove Processing Time from channel altogether (it exists as a property of the service). If the WG feels that we shoujld record didfferent typical processing tomes for each channel then that will need to be supported but my proposal is just to leave it as a property of the service, no more.

 

Mon, 14/11/2016 - 13:58

Hi Phil,

I think ContactPoint could also benefit from the "if accessed through" relation:

Public Service --> has contactPoint --> ContactPoint --> if accessed through --> Channel.

Something similar could be done for processing time if needed, though this would imply defining processing time as an entity rather than a literal.

 

It is a shame Channel is defined as an entity that does not (and cannot) keeps its Service in mind. An alternative would be to adopt a term that does allow this, such as https://schema.org/ServiceChannel. Then we could have:

PublicService --> availableChannel --> ServiceChannel --> relatedTo --> Channel

Where ServiceChannel keeps track of:

  • Cost
  • Processing Time
  • Contact Point (either through a separate entity or direct predicates on ServiceChannel)
  • Temporal info (when was this channel created/closes)
  • Opening Hours

A final alternative I see is definition of a new term, eg: ServiceContext, where all non-generic info is stored. There can be maximum one single context without a "is related to channel" relation to represent information that is valid for all contexts. To clarify:

PublicService --> hasContext --> ServiceContext

PublicService no longer contains processing time, spatial, contact point

ServiceContext contains cost, processing time, contact point, temporal, spatial and opening hours.

A ServiceContext either specifies a Channel, in which case all information is related to that Channel, or it does not, in which case the information is applicable to all Channels (or for the case where Channels are not being modelled).

Wed, 16/11/2016 - 06:45

I sympathise with this, Dieter. A general question for the WG is, I think, whether we should adopt a general principle of aligning with schema.org modelling. At this stage, it would be difficult to make such a substantial change but we can discuss it in the telco. 

Thu, 17/11/2016 - 07:23

Phil, as we have discussed, there is an activity that is currently kicking off which aims at aligning the Core Vocabularies RDF to schema.org. Currently, this does not include in its scope the change of the Core Vocabularies conceptual models in order to align with schema.org at that level. To do so, any proposed changes would have to be submitted as change requests to the respective working groups, and would then have to be considered, discussed and approved/rejected by them. 

Thu, 17/11/2016 - 07:34

Hi Dieter, 

 

thank you for your feedback. I do see your point, but there are indeed different ways of modelling the same information. 

 

ContactPoint (homepage)

Since homepages are defined as Channels by CPSV, this means that any homepage can get a ContactPoint. Although strange, one could argue that this makes sense. However, once multiple services are available from a single homepage, each having a different ContactPoint, it becomes impossible to link the service to its own contact point.

 

I believe that the direct relationship between Public Service and ContactPoint is addressing your concern. I see there that the cardinality of the has Contact Point relationship is [0..1], relaxing this to [0..n] would allow several contact points to be attached to a homepage, hence accomodating, wherever required, a different contact point per service. 

 

ContactPoint (physicallyLocatedAt)

Once a single location is available for multiple services, it becomes impossible to identify the proper contactPoint. Two examples:

- The location used defines a building (rather than a specific counter) where multiple government agencies are located. Because each agency adds their own contactpoint information to their location (the shared building), the information gets mixed up.

- The location used defines a counter where multiple services are availble. Each of these services has the same location, but a different phone number or email. Once again, information gets mixed up.

 

See my previous comment. 

 

Cost (homepage/physicallyLocatedAt)

Defining a cost on a homepage or location does not make sense, it is the service that has a cost.

 

Not necessarily. The cost of a public service may differ based on a Channel. That was the input provided by the members of the Working Group. 

Thu, 17/11/2016 - 11:18

Hello Nikos,

I think you might have missed the point of my objection, so let me further clarify with an example. (Omitting most namespaces for brevity.)

Let's say I have 2 different services on my website, with a different cost.

:service1 a :PublicService.
:service1 foaf:homePage :myWebsite.
:myWebsite :hasCost :costInfo1.
:service2 a :PublicService.
:service2 foaf:homePage :myWebsite.
:myWebsite :hasCost :costInfo2.

If someone reads this information, he will not know which cost corresponds to which service.

 

For contactpoint the same problem will occur if the contactpoint is linked to the channel.

Thu, 17/11/2016 - 20:21

ServiceChannel proposed by Dieter would actually be an association class (in UML-terms) on the PublicService-Channel association, with its own properties like Cost etc. This brings me to the point that the PublicService-Channel relation only points from PublicService to Channel and not the other way round as it should when the same Channel can provide for several PublicServices.  

Fri, 18/11/2016 - 08:14

In my opinion this problem is bound to the definition of Contact Point. Since a Channel is defined as "the medium through which an Agent provides, uses or interacts in another way with a Public Service", in a sense a channel is already a “contact point”, intended as a physical way to establish a contact with the service. Of course, however, a channel has a (typically unique) address. If we understand Contact Point as an address, the problem disappears. Home page example: if multiple services share a Web page as a channel, such Web page has a unique address. Of course, each service may also have other channels (say, a phone or an email), each one with its own address. The same for a physical location: one shared channel (a physical office), multiple specific channels (phones or emails).

To solve the issue, I would suggest to rename "hasContactPoint" into "hasAddress", and to provide further examples of services having multiple (shared and non-shared) channels.

The problem with hasCost is a different one. Although of course the cost of a public service may differ based on the Channel, this is indeed the cost of the specific sub-activity (say, the service request) that uses that specific channel. In any case, it is not the channel that has a cost (unless we mean the cost needed to buy the physical device).

Thu, 24/11/2016 - 12:52

I do see a difference between a ContactPoint and a Channel. The mailbox to which to send your tax forms is a Channel, but not a ContactPoint, since I cannot (should not) use it for asking questions related to the service.

 

I agree with Nicola on the Channel having something that makes them reachable (though I would avoid the term address since it is often associated to a street address). Because of this, I also oppose renaming "hasContactPoint".

 

The problem with Cost has been solved in the Final Draft version.

Fri, 25/11/2016 - 21:13

I think if we were starting from scratch we might use the schema.org model as Dieter suggests, but we're further along than that and we have agreed to use schema.org where it suits our model, but not - for the time being at least - to change the model to fit it. Having added in the 'ifAccessedThrough'; property to link a cost to a channel, and adding in the contact point for the service as a whole, I believe we've gone as far as we can for this round. It may be that, as Nikos indicates, that might happen via a future process.

Login or create an account to comment.