Prototyping Subjective Locations in DPV

Testing proposed concepts with specific use-cases and examples
published:
by Harshvardhan J. Pandit
is part of: Data Privacy Vocabulary (DPV)
DPV DPVCG semantic-web Working Note

In the previous post, I proposed subjective location concepts such as 'home' and 'work', and expanded that in another previous post for 'private' and 'public'. In this post, I continue that discussion by exploring the feasibility of those concepts with specific use-cases and examples.

Use-Cases

  1. Specify location as Home which is a Private and Personal place, and which itself may have more information such as postal addresses.
  2. Specify location as Work which is Private place, and which can have multiple offices all of which would come under it.
  3. Specify location as Device where some information is stored in virtual folders within a specific device's storage, and which is managed by the User.
  4. Specify location as App where some information is stored within a software and is managed by that software. Additionally, specify that the app's storage is within the device storage, but is not accessible to the user.
  5. Specify location as Browser for Cookies which are set by visiting the internet by Service Provider and Third Parties. These are accessible to the user, but are set by the websites. Here the distinction is that the user can see and interact with the cookies, but they do not have control over the 'location' beyond this.
  6. Specify location as asked by a Browser or App where the user can specify their Current Location or their Local Area or City or Region or Country.
  7. Specify location as a shop which is open to the public and is monitored by a CCTV.
  8. Specify location as a shopping mall which has common areas for sitting etc. and shops which are privately owned but can be visited by the public, and admin areas which are not open to the public.

UC1 & UC2: Home and Work

Assuming we have the top concepts from , we can have the following taxonomy:

loc:Home a skos:Concept, loc:SubjectiveLocation ;
    skos:broader loc:PersonalSpace .

loc:Work a skos:Concept, loc:SubjectiveLocation ;
    skos:broader loc:PrivateSpace .

And then use it in a process like this:

#1 Direct use of location
# read as: Process has location Home
ex:Process1 a dpv:Process ;
    dpv:hasLocation loc:Home .

#2 Add postal address
# read as: Process has location Home with address x
ex:Process2 a dpv:Process ;
    dpv:hasLocation [
        a dpv:Location, loc:Home ;
        schema:address [
            a schema:PostalAddres ; # data goes here
        ] ;
    ] .

#3 Multiple locations under one label
# read as: Process has location Work which includes x, y
ex:Process3 a dpv:Process ;
    dpv:hasLocation [
        a dpv:Location, loc:Work ;
        skos:narrower ex:OfficeX, ex:OfficeY ;
    ] .

UC3 & UC4: App and Device

The app and device storages are Virtual Locations unlike cities and home/work which are Physical Locations. Therefore, to distinguish these, we have to create a taxonomy that reflects this distinction (we assume locations are physical unless otherwise noted, so we only create the concept for virtual location). Further, we have to distinguish between the 'app/device' and the 'storage' within these - as otherwise there is a conflict between the concepts from LOC and TECH extensions if both have the same label, and it would be confusing as to which is used when and where without any distinction. In theory, we can say an app (as a software) or a device (as a hardware) can also be location in addition to the technology concepts, but it gets complicated the more relations we introduce like this. Further, it is also useful to distinguish between a 'device' and 'device storage' as it allows additional metadata to be associated with the storage - such as whether it is encrypted, or there are specific protections like access control governing it.

However, we are not only thinking of the storages, as the app and devices are also operating environments where execution of processing operations and technologies can take place. Therefore, we want a concept that represents both - or allows us to state with distinction - that the app is used to run a process and/or store data.

Options considered to do this:

  1. App - rejected as this is confusing with tech:App
  2. AppStorage - not sufficient to denote processing takes place in app
  3. AppLocation - better, but might get confused with 'app location' as in 'location of the app'
  4. WithinApp - clearly states location is 'within the app' so if used with processing then it means it takes place within the app
  5. InApp - same as above, though from a grammatical pov, 'within' is better than 'in' as withhin specifically represents inclusion within a boundary whereas in has ambiguity e.g. 'in 2 days' can mean 'within 2 days' or 'after 2 days'

Based on the above, and the choice betweenn WithinApp and AppLocation, I prefer WithinApp as it is intuitive to me and makes sense when using with data. We can further expand this to explicitly state the storage within the app, or for devices the trusted execution environment.

loc:WithinApp a skos:Concept, loc:VirtualLocation, loc:SubjectiveLocation ;
    skos:broader loc:PrivateLocation, loc:LocalLocation .
loc:WithinAppStorage a skos:Concept, loc:VirtualLocation, loc:SubjectiveLocation ;
    skos:broader loc:PrivateLocation, loc:LocalLocation, loc:WithinApp .
# this replaces dpv:WithinDevice in future versions, see Misc. changes at the end
loc:WithinDevice a skos:Concept, loc:VirtualLocation, loc:SubjectiveLocation ;
    skos:broader loc:PrivateLocation, loc:LocalLocation .
loc:WithinDeviceStorage a skos:Concept, loc:VirtualLocation, loc:SubjectiveLocation ;
    skos:broader loc:PrivateLocation, loc:LocalLocation, loc:WithinDevice .
# TEE = Trusted Execution Environment
loc:WithinDeviceTEE a skos:Concept, loc:VirtualLocation, loc:SubjectiveLocation ;
    skos:broader loc:PrivateLocation, loc:LocalLocation, loc:WithinDevice .

Using it in practice:

#1 direct use
# read as: Process takes place within app
ex:Process a dpv:Process ;
    dpv:hasLocation loc:WithinApp . 

#2 indicating app runs on device
# read as: Process takes place within app which is within device
ex:Process a dpv:Process ;
    dpv:hasLocation [
        a dpv:Location, loc:WithinApp ;
        skos:broader loc:WithinDevice ;
    ] .

#3 indicating app with local and remote locations
# read as: Process takes place within app and on cloud in EU
ex:Process a dpv:Process ;
    dpv:hasLocation loc:WithinApp ;
    dpv:hasLocation [
        a dpv:Location, loc:CloudLocation ;
        skos:broader loc:EU ;  # located in EU
    ] .

UC5: Browser and Cookies

As with the apps/devices, we distinguish between browsers as storage and processing environments. Further, even though browsers don't necessarily have storage 'within' them but use the underlying filesystem, it is practical to represent the storage as being used and managed by them, and then separately represent the possibility for the user to manage/access the location/resources.

loc:WithinBrowser  a skos:Concept, loc:VirtualLocation, loc:SubjectiveLocation ;
    skos:broader loc:PrivateLocation, loc:LocalLocation .

loc:WithinBrowserStorage  a skos:Concept, loc:VirtualLocation, loc:SubjectiveLocation ;
    skos:broader loc:PrivateLocation, loc:LocalLocation, loc:WithinBrowser .

With this, the use of cookies or other types of technologies can be indicated to be stored within the browser. We don't directly model a cookie as a storage location as it is a form of storage technology, which is stored within the browser or on the user's device or within the app - as dictated by the context.

ex:Process a dpv:Process ;
    dpv:isImplementedUsingTechnology tech:Cookie ;
    dpv:hasLocation loc:WithinBrowserStorage .

This distinction is better as it places the emphasis to explicitly dictate whether a local storage is being used or not (cookies can also be temporary, or be transmitted as packets of data). Further, as regulations clearly distinguish between storage of the user (which can be indicated by using loc:PersonalSpace with the browser storage), this modelling is also consistent for any other forms of data storage beyond cookies - e.g. using other browser storage mechanisms, storing files on user device, etc. to the device.

If we did want to represent cookies as a location, then it would be confusing to label them e.g. CookieStorage, CookieLocation, WithinCookie are ambiguous or confusing.

UC6: Granular Geo-Location

The granularity of a subjective location from a geo-physical designated location (e.g. city, region, country) is a difficult to isolate categorisation. For our purposes, we want to say things such as "home is within this city" or "workplace in regions x and y". This is easy to express as:

ex:Process2 a dpv:Process ;
    dpv:hasLocation [
        a dpv:Location, loc:Home ;
        skos:broader loc:IE-D ; # Dublin, Ireland
    ] .

Using the same notations, we can also specify rooms within a home:

ex:Process a dpv:Process ;
    dpv:hasLocation ex:HouseRoom .
ex:HouseRoom a dpv:Location ; 
    skos:broader ex:House .
ex:House a dpv:Location, loc:Home ; # vice-versa
    skos:narrower ex:HouseRoom .

Since the SKOS broader/narrower relations are transitive, the granularity is automatically available as soon as the subjective concept hooks in to an objective/known geo-physical location. In the above location, the first instance of Home is stated to in the broad area of Dublin. Using the LOC knowledge base, we can find that the home's city is Dublin, region is Dublin, country is Ireland, and it is in EU.

UC7 & UC8: Hybrig Private+Public Areas

The relations from SKOS broader/narrower also provide useful inference of private/public places, as if place A has as broader place B, then it inherits the private/public attribute from it, while also having the possibility to add or change it on its own.

#1 Private room in private home
loc:Home a loc:SubjectiveLocation ; skos:broader loc:PersonalSpace .
ex:Room a loc:SubjectiveLocation ; skos:broader loc:Home .
# infer: ex:Room skos:broaderTransitive loc:PersonalSpace .

#2 Publicly accessible area in shop
loc:Shop a loc:SubjectiveLocation ; skos:broader loc:PrivatelyOwnedPlace .
loc:ShopPublicArea a loc:SubjectiveLocation ; 
    skos:broader loc:Shop, loc:PubliclyAccessibleSpace .
# infer: loc:ShopPublicArea skos:broaderTransitive loc:PrivateSpace .
ex:SecurityMonitoring a dpv:Process ;
    dpv:hasPurpose dpv:EnforceSecurity ;
    dpv:hasLocation loc:ShopPublicArea ;
    dpv:isImplementedUsingTechnology tech:CCTV .

#3 Shopping Mall with public and private areas
loc:ShoppingMall a loc:SubjectiveLocation ; skos:broader loc:PrivatelyOwnedPlace .
ex:ClothingShop a dpv:SubjectiveLocation, loc:Shop ;
    skos:broader loc:ShoppingMall .
ex:PublicSeating a loc:SubjectiveLocation ;
    skos:broader loc:PrivatelyOwnedPublicPlace, loc:ShoppingMall .
ex:SecurityOffice a loc:SubjectiveLocation ;
    skos:broader loc:PrivateSpace, loc:ShoppingMall .

Other Misc. Changes

  1. dpv:PrivateLocation and dpv:PublicLocation are narrower than dpv:LocalLocation - this is incorrect. There can be private/public locations that are not local. These should be moved outside the local taxonomy.
  2. The entire dpv:LocationLocality concepts can be moved to LOC e.g. dpv:WithinDevice and dpv:RemoteLocation have an overlap with the new concepts in LOC. It would be better to first repeat them in LOC as subclasses of the DPV concepts, and then deprecate them in future iterations.