Do we need to capture the 'jurisdiction of a service’?

During the WG meeting of 9 January, it was questioned whether the Core Public Service vocabulary needs to capture the 'jurisdiction of a service'. What would such a property mean? How is it different from the spatial coverage of a service?






Sat, 12/01/2013 - 11:15

For me there are two aspects to jurisdiction of a service.  First there is the geographical area that an organisation has responsibility for, eg a local authority area, and secondly there is the area of business that an organisation has responsibility or jurisdiction for, eg driving licences are issued by DVLA in the UK.  It seems we have the first aspect, eg spatial, already covered.  But maybe we need something for the second if we believe that administering policy or legislation is different from those who create it and it is important to know that aspect, ie it is not already covered by the Legislation/Policy to Agent relationship?  In the example of driving licences the policy and legislation for these in the UK is handled by the Department of Transport whilst the administration of the issuing of licences is DVLA.  A similar situation arises in the UK with health where policy is set by Dept of Health and delivery is by NHS.  So do we need to add an additional relationship to Policy/Agent to cover this aspect?

Thu, 17/01/2013 - 17:23

I think we're acovered in this John but let me see if you agree.

I'll stick to ther driving licence example but take the point that it applies to health as well. What follows is a partial example of 4 linked classes:

  • the piece of legislation (created by the Department of Transport);
  • the rules that govern the issuing of licences (defined by the DVLA);
  • the DVLA itself;
  • the driving licence issuing service.
<> a cpsv:LegislationOrPolicy ; dcterms:title "Driving Licence Act 1948"; dcterms:creator [dcterms:title "Department of Transport"]. <> a cpsv:Rule; cpsv:implements <>; dcterms:creator <>. <> a org:FormalOrganization ; dcterms:title "DVLA"; cpsv:provides <>. <> a cpsv:PublicService; dcterms:title "Driving Licence Issuing Service"; dcterms:type <URI from ESD Toolkit for this >; dcterms:description "DVLA's service for issuing driving licences"; dcterms:spatial <>; cpsv:follows <>.

There is no link (here) between the Public Service and the Department of Transport. The links are from the service to the DVLA, which both created the policy and provides the service, and from the DVLA to the legislation that was created by the DoT.

How does this look to you?

Fri, 18/01/2013 - 08:44

Phil, I'll take your word for it but if we are going to post this or something similar as a use case to explain the concept then it would be more helpful, to me at least, if it were in plain lanaguage and not in all the funny hieroglyphics above ...-) 

Thu, 24/01/2013 - 09:19

I had the same concern as John, but from Phil's example I think we have the jurisdictional service functional item covered. However, I think its useful to have a statement/faq specifically about modelling these typs of relations and very clear examples of this particularly where there are multiple layers of government administration involved.

That being said, going back to the core question 'how would this item differ from the spatial coverage' I think that answer needs to be expanded too. At least in my part of the world there is an inexact mapping between spatial coverage and jurisdictional responsibility at multiple layers of government.

Tue, 05/02/2013 - 09:42

Thank you Baden.

During the previous WG call we resolved that for now we woud not include a new property to link to the DC class of Jurisdiction, *but* that we would highlight this as an issue in the draft spec when it goes out to public review (which, I hope, we will resolve to do during tomorrow's meeting).

The inexact overlap between geography and jurisdiction is the underlying issue here as you say. The question is whether in practical terms that is something we need to capture in the model. The general feeling is that we probably don't but if someone has a clear use case that demands it, OK, we can add it in.

Login or create an account to comment.