A structural way to represent address supplements.

[EmielPwC]

The SEMIC team received the following request through email:
Is there a structural way to represent address supplements such as c/o, Rear house 2nd floor etc. in http://www.w3.org/ns/locn#Address ?
For address supplements like c/o (in care of) would it be possible to add an "addressSupplement" property?

[EmielPwC]

For those supplements that are location related such as Rear house and 2nd floor one can include these in the locator designator property or locator name property. You can use the locator designator property most of the time, but if the location has a proper name you should use the locator name property.

In the current version there is no support for other supplements and therefore they can only be included in the full address property.

We will investigate how this can be integrated into the next release of the Core Location Vocabulary.
Anybody with an interest or a possible solution feel free to share your insights.

[dg7op]

I’d prefer an extra attribute “addressSupplement” to represents an additional information such as c/o (in care of).

[akuckartz]

The "INSPIRE Data Specification on Addresses" deals with such details. See: https://inspire.ec.europa.eu/id/document/tg/ad

[dg7op]

I searched for "c/o" and for "in care of" in this 249 pages long specification and didn't find anything

[EmidioStani]

I believe c/o is more a relation between a Person and a Address

[EmidioStani]

Inside the https://inspire.ec.europa.eu/id/document/tg/ad , it is written:

5.3.1.1.6. Locator designator
The most common example of a locator is a “designator” like an address number or building number,
optionally with an extension and even a second extension. Other common address designators are
floor identifiers (like 0, 1, 2, 3 etc.) and unit identifiers (e.g. appartment A10, A11, A12 etc.).
...
As shown in Annex G, the traditions and rules for the composition of address designators vary widely
across the different countries and regions of Europe. On the basis of the INSPIRE reference material a
total of 14 different locator types has been identified and represented in the locator type code list.

in the Annex G, there is a table H with a list of Locator Designator types.

Now, in section 5.3.1.2. UML Overview, there is a LocatorDesignator dataType, that includes the designator and its type.
However, in Core Location, the Address class includes the locator designator and the locator name.

So, if we want differentiate the designator types, I see these options:

1. creating sub-properties of locator designator, keeping in mind that Core Location as vocabulary allows to have multiple locator designator
2. creating sub-components of the Address, like the AdminUnit class, on this aspect, this issue is similar to Datatypes of SEMIC-Address:Address.adminUnit and INSPIRE-Address:AddressRepresentation.adminUnit differ #25.

[dg7op]

I believe c/o is more a relation between a Person and a Address

Usually, I only have recipient data in my system with a reference to his/her address.
Why would I save an additional person? Often it wouldn't be possible, since I only have the name and my system might require additional data like gender or birth date.

[EmidioStani]

Hello @dg7op , indeed you have a reference to that person, via Its URI, and the reference to an address, the c/o would a relation between the 2 reference, you don't need an additional person.

[dg7op]

reference to that person, via Its URI

Hi @EmidioStani, which person? The recipient? Can you please provide an (pseudocode?) example for such a relation between an address and its owner with c/o-information in it, so that I understand what you mean. I don't get where c/o is going to be stored, because a relation in my understanding is just a reference to an attribute of an object or to its id

[EmidioStani]

Hello @dg7op , an example would be:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix locn: <http://www.w3.org/ns/locn#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://example.com/person/PS1> rdf:type <http://www.w3.org/ns/person#Person> ;
foaf:givenName "John"@en;
foaf:familyName "Smith"@en;
<http://example.com/relation/c_o> <http://example.com/address/AD1> .

<http://example.com/relation/c_o> rdf:type <http://www.w3.org/2002/07/owl#ObjectProperty> ;
rdfs:label "c/o" ;
rdfs:comment "A relation between a person and a mail address where such person is in care of".

<http://example.com/address/AD1> rdf:type locn:Address ;
locn:fullAddress "123 Street St. City, ST 99999"@en .

[jakubklimek]

Based on today's webinar, we should re-use the structured way of providing multiple designators for one address:

[dg7op]

Hello @dg7op , indeed you have a reference to that person, via Its URI, and the reference to an address, the c/o would a relation between the 2 reference, you don't need an additional person.

Hi @EmidioStani, a c/o-address has 3 components:
1. Address of a person or a company
2. Intended recipient, who is maybe not registered under this address and whose name is not visible on the mailbox.
3. Addressee that is accepting the correspondence for (i.e. is in care of) the intended recipient and who is the owner of the address and whose name is visible at this location. This can be a name of a business where the intended recipient has her workplace or a person where the the intended recipient is staying. Other scenarios are also possible.

If there is only a relation between 1 und 2 the letter or package might not arrive at all.

In your code sample there is only a relation between 1 und 3 without the intended recipient. Missing the relation to 2 might lead to privacy and multiple other legal issues, since 3 may believe to be the intended recipient and open the letter or the package. So, if c/o is a relation between a Person and an Address, your code does need an additional person:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix locn: <http://www.w3.org/ns/locn#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://example.com/person/PS1> rdf:type <http://www.w3.org/ns/person#Person> ;
foaf:givenName "John"@en;
foaf:familyName "Smith"@en;
<http://example.com/relation/addressee> <http://example.com/address/AD1> .

<http://example.com/person/PS2> rdf:type <http://www.w3.org/ns/person#Person> ;
foaf:givenName "Jane"@en;
foaf:familyName "Smith"@en;
<http://example.com/relation/recipient> <http://example.com/address/AD1> .

<http://example.com/relation/addressee> rdf:type <http://www.w3.org/2002/07/owl#ObjectProperty> ;
rdfs:label "Addressee" ;
rdfs:comment "A relation between a person and a mail address where the person is an addressee at this address and accepts correspondence in care of other recipients at this address".

<http://example.com/relation/recipient> rdf:type <http://www.w3.org/2002/07/owl#ObjectProperty> ;
rdfs:label "Recipient" ;
rdfs:comment "A relation between a person and a mail address where such person is an intended recipient ".

<http://example.com/address/AD1> rdf:type locn:Address ;
locn:fullAddress "123 Street St. City, ST 99999"@en 

To comply with your data model I'd have to process such c/o-addresses by keeping a (minimal) representation of 3 with its/her mail address, though 3 has nothing lost in my system and, if 3 is a person, I may break the law by storing/processing her personal data without her explicit consent. And, as I wrote above, often it would be impossible to store a person just by her name without further information about her like gender or birth date (same logic applies to businesses: company name might not be enough for processing business data without e.g. tax number).