Extend DPV-PD with missing Location concepts

[besteves4]

Hi,
This is not a new issue, we had discussed it previously via the public mailing list but I think it got lost in the process (link to the discussion on the mailing list).

Summary of the issue: We should consider extending DPV-PD's Location with subtypes for postal code, locality, region, street and house number as it right now only includes birthplace, country, GPS coordinates, room number and travel history.

Term: House Number
Description: Information about the number of a house in a street.
Subtype of: Location

Term: Street
Description: Information about a street.
Subtype of: Location

Term: Postal Code
Description: Information about a postal code of a location. It can be defined by a series of letters or digits or both.
Subtype of: Location

Term: Locality
Description: Information about the locality of a location, e.g., it can be a city, town or village.
Subtype of: Location

Term: Region
Description: Information about the region of a location. It can be an area of a country or the world which has certain characteristics but not always fixed boundaries.
Subtype of: Location

Later on we can use something like rdfs:seeAlso to align these terms with VCard, SEMIC Location Vocab, Gist and so on.

[coolharsh55]

We should already have LocationLocality to specify something is local or remote, and Region alongside Country and City.

The other concepts relate to Addresses, so should be their subtypes instead of directly Location? Separately, we can grow an infinite list while modelling the world, so my preference is to get the top concepts right and keep extending downwards. So house number etc. need an appropriate hierarchy that ties it to addresses and to location.

[besteves4]

Hi.

The other concepts relate to Addresses, so should be their subtypes instead of directly Location? Separately, we can grow an infinite list while modelling the world, so my preference is to get the top concepts right and keep extending downwards. So house number etc. need an appropriate hierarchy that ties it to addresses and to location.
Postal Code as a subtype of dpv-pd:PhysicalAddress and dpv:LocationLocality?
Street as a subtype of dpv-pd:PhysicalAddress and dpv:LocationLocality?
House Number as a subtype of dpv-pd:Street and dpv:LocationLocality?

dpv-pd:RoomNumber is a subtype of dpv-pd:Location, shouldn't it also be connected as a subtype of dpv-pd:PhysicalAddress, or better dpv-pd:HouseNumber, and dpv:LocationLocality ?

[coolharsh55]

LocationLocality is a relative expression of how local or remote a location is. I don't think it should used to denote addresses. Also, I don't recall where we got RoomNumber from, but it feels out of place in terms of being too specific for addresses. Either we add all components of address (streets, post codes), or none. Ideally, we point to other vocabularies that are available for addresses. That said, if someone has use for these concepts and they are not modeled elsewhere or are better off to be modeled in DPV, we should implement them.

[pmcb55]

Hi folks - so I'm not sure this request is specifically related to this topic (so if there's a more suitable issue, maybe point me there), but I'm just looking for Location/Address properties to allow me associate values for instances of existing DPV-PD classes like dpv-pd:Street and dpv-pd:PostalCode, for example, to include new DPV-PD properties for: dpv-pd:hasStreet and dpv-pd:hasPostalCode respectively.
See this example Turtle from @besteves4: https://github.com/besteves4/dpv-stuff/blob/main/represent-addresses/address%20with%20dpv%20and%20dpv-pd.ttl

Without these properties being added to DPV-PD, I'd have to resort to using Schema.org properties, or vCard - but those properties expect string literal values, whereas (as can be seen in the Turtle linked to above), using the DPV-PD classes means we could have DPV-PD properties with the associated Range of the corresponding DPV-PD Class, for example see this line in the Turtle (https://github.com/besteves4/dpv-stuff/blob/383216ffe169c9069e5bc3a7c5df79b7a5aebb95/represent-addresses/address%20with%20dpv%20and%20dpv-pd.ttl#L50C4-L50C87):

  dpv-pd:hasStreet [ a dpv-pd:Street ; rdf:value "Calle Mayorazgo de Duarte 277" ] ;

Now I think the Range of these properties is debatable (e.g., should they be string literals (like in Schema.org or vCard), or object references (like the Blank Node example above)), but I think that's perhaps a separate issue.

The real question here is does DPV (as a group) wish to define properties like these in the first place at all...!?

[coolharsh55]

Hi. So the issue at this point is more about removing the concepts such as RoomNumber which are too specific where others are not. So far we have considered not adding properties to the personal data categories. Adding properties for specific personal data classes would mean we accept properties for other concepts as well, e.g. hasName, hasNationality, hasBankAccountNumber - of which there would be countless similar examples. So I do not think such properties should be in the scope of the group as we limit the scope to the categories of information i.e. the classes. The sem-web mailing list should have better knowledge about depicting postal addresses.

[TallTed]

It's important to recognize and handle the fact that many areas do not have street numbers, nor street names, nor even municipality names, nor postal codes, nor...

Not to put too fine a point on it, addresses are best handled as a few lines of text, which may be broken out as something like address line 1, address line 2, etc. I believe 6 lines are the maximum in actual use. See falsehoods programmers believe about postal addresses. See also falsehoods programmers believe about human identity (including names).

[ghurlbot]

Comment by @coolharsh55 via IRC channel #dpvcg on irc.w3.org

this issue was discussed in today's meeting and will be resolved/closed as it is outside the scope of the current work to provide properties for each personal data category.

[ghurlbot]

Comment by @coolharsh55 via IRC channel #dpvcg on irc.w3.org

the location concepts in this issue (e.g. street) will be added to DPV-PD taxonomy, the group has agreed that developing properties for each PD concept is not feasible and in scope at this moment

[coolharsh55]

Added these concepts to PD (reflecting earlier resolution). (edit: see live version at https://harshp.com/dpv/pd/#vocab-tracking - mirrors the dev branch of this repo)

Though I think we should point to other vocabularies which specifically model addresses etc. - see Core Location vocabulary https://semiceu.github.io/Core-Location-Vocabulary/releases/2.0.2/. Similarly, see Core Person vocabulary for information about a 'Person' https://semiceu.github.io/Core-Person-Vocabulary/releases/2.1.0/ and Core Business vocabulary for information on organisations/legal entities https://semiceu.github.io/Core-Business-Vocabulary/releases/2.1.0/