Address props: review W3C LOCN and EBG ontologies

[VladimirAlexiev]

The W3C LOCN ontology https://www.w3.org/ns/locn has a smattering of other Address props, maybe some could be useful. Our EBG ontology added even more:

• Described in detail in this gdoc
• See how they're used here https://github.com/euBusinessGraph/eubg-data/blob/master/model/ebg-ontology.ttl#L704
• Diagram of their use https://github.com/euBusinessGraph/eubg-data/blob/master/model/images/company.png (nodes Address and GeoCoordinates)

Candidates for inclusion:

• geo precision
• TODO

Unfortunately, LOCN+EBG are not very popular.

---

After fixing #253, these props make sense: addressCountry > addressRegion > countyCode (they're literals, forming a hierarchy). But I would prefer to use more culture-neutral designations for "region" and "county". Eg in Bulgaria these are called "oblast" and "obshtina", in Germany "land" and "bezirk" etc.

Here's a comparison:

Schema+GS1	LOCN+EBG	Geonames feature code
addressCountry	adminUnitL1	P.PCLI, etc
addressRegion	adminUnitL2	A.ADM1
countyCode	adminUnitL3	A.ADM2
	adminUnitL4	A.ADM3
	adminUnitL5	A.ADM4

[nissimsan]

Note: https://github.com/w3c-ccg/traceability-vocab/pull/282 ^

[OR13]

What is the suggested change?

[OR13]

@nissimsan @BenjaminMoe please comment.

[BenjaminMoe]

Need concrete examples on issue to move forward on this.

Posting example from @VladimirAlexiev 's comment: https://github.com/euBusinessGraph/eubg-data/blob/master/model/ebg-ontology.ttl#L704

locn:Address a rdfs:Class ;
  rdfs:label "Address" ;
  skos:definition "Mailing or physical address of a company" ;
  skos:scopeNote "Should be linked as registered address (one) or other address (multiple).",
    "Every data provider should strive to provide NUTS3 for each address. This can be done in cooperation, using the techniques described in Address Calculations above." .

locn:addressArea a owl:DatatypeProperty ;
  schema:domainIncludes locn:Address ;
  schema:rangeIncludes xsd:string , rdf:langString ;
  rdfs:label "address area (neighbourhood/quarter)" ;
  skos:definition "Part of a city, village or neighborhood." ;
  skos:scopeNote "Not likely to appear, but we have Coordinate resolution corresponding to this field." .

locn:adminUnitL1 a owl:ObjectProperty ;
  schema:domainIncludes locn:Address ;
  schema:rangeIncludes ramon:NUTSRegion ;
  rdfs:label "admin unit level 1" ;
  skos:definition "Country of the address" ;
  skos:example "nuts:IT (Italy)." .

[mkhraisha]

@TallTed suggests switching to a string address field rather than using a prescribed set of fields because multiple places do not support the schema.org address format.

[nissimsan]

UN/CEFACT defines address line 1 through 5. Discussion on the call to potentially go with something looser like that.

[OR13]

Need a complete example for a "new proposal" in JSON-LD.

[nissimsan]

https://service.unece.org/trade/uncefact/vocabulary/uncefact/#Address-properies

[TallTed]

@nissimsan --

Neither https://service.unece.org/trade/uncefact/vocabulary/uncefact/#Address-properies nor https://service.unece.org/trade/uncefact/vocabulary/uncefact/#Address-properties ( nor https://service.unece.org/trade/uncefact/vocabulary/uncefact#Address-properies nor https://service.unece.org/trade/uncefact/vocabulary/uncefact#Address-properties ) appear to exist. I don't understand your comment here.

[nissimsan]

@TallTed, that's odd....

[TallTed]

Bah. I didn't wait long enough for the huge page to load, and then for my browser to find the #Address-properies fragment.

(If they're not already aware of and fixing the properies typo, we should raise it to their attention.)

I'm also surprised to see that they worded the numbers, as line1, line2, line3, line4, line5 are trivial to order properly in output, while lineFive, lineFour, lineOne, lineThree, lineTwo are not (as evidenced in the screenshot above). More UnCoolUris to change....

[nissimsan]

@nissimsan to consider this given that the CEFACT vocab is progressed from draft.

Cross reference from the UN repo.

[nissimsan]

Suggestion on the call to only update the linked data terms, not the JSON Schemas.

[nissimsan]

Action: mock a PR on the issue for discussion.

[BenjaminMoe]

Something like this?

$linkedData:
  term: PostalAddress
  '@id': https://schema.org/PostalAddress
title: Postal Address
description: >-
  The location at which a particular organization or person may be found or
  reached.
type: object
properties:
  type:
    type: array
    readOnly: true
    const:
      - PostalAddress
    default:
      - PostalAddress
    items:
      type: string
      enum:
        - PostalAddress
  name:
    title: Name
    description: The name of the entity in text.
    type: string
    $linkedData:
      term: name
      '@id': https://schema.org/name
  streetAddress:
    title: Street Address
    description: >-
      The street address expressed as free form text. The street address is
      printed on paper as the first lines below the name. For example, the name
      of the street and the number in the street or the name of a building.
    type: string
    $linkedData:
      term: streetAddress
      '@id': https://service.unece.org/trade/uncefact/vocabulary/uncefact/#lineOne
  addressLocality:
    title: Address Locality
    description: Text specifying the name of the locality; for example, a city.
    type: string
    $linkedData:
      term: addressLocality
      '@id': https://service.unece.org/trade/uncefact/vocabulary/uncefact/#lineTwo
  addressRegion:
    title: Address Region
    description: >-
      Text specifying a province or state in abbreviated format; for example,
      NJ.
    type: string
    $linkedData:
      term: addressRegion
      '@id': https://service.unece.org/trade/uncefact/vocabulary/uncefact/#lineThree
  addressCountry:
    title: Address Country
    description: >-
      The two-letter ISO 3166-1 alpha-2 country code.
    type: string
    $linkedData:
      term: addressCountry
      '@id': https://service.unece.org/trade/uncefact/vocabulary/uncefact/#lineFour
  crossStreet:
    title: Cross Street
    description: >-
      A street intersecting a main street (usually at right angles) and
      continuing on both sides of it.
    type: string
    $linkedData:
      term: crossStreet
      '@id': https://service.unece.org/trade/uncefact/vocabulary/uncefact/#lineFive
  countyCode:
    title: County Code
    description: >-
      A code that identifies a county. A county is a territorial division in
      some countries, forming the chief unit of local administration. In the US,
      a county is a political and administrative division of a state.
    type: string
    $linkedData:
      term: countyCode
      '@id': https://gs1.org/voc/countyCode
  postalCode:
    title: Postal Code
    description: Text specifying the postal code for an address.
    type: string
    $linkedData:
      term: postalCode
      '@id': https://service.unece.org/trade/uncefact/vocabulary/uncefact/#postcodeCode
  postOfficeBoxNumber:
    title: Post Office Box Number
    description: >-
      The number that identifies a PO box. A PO box is a box in a post office or
      other postal service location assigned to an organization where postal
      items may be kept.
    type: string
    $linkedData:
      term: postOfficeBoxNumber
      '@id': https://service.unece.org/trade/uncefact/vocabulary/uncefact/#postOfficeBox
additionalProperties: false
required:
  - type
example: |-
  {
    "type": ["PostalAddress"],
    "name": "Lebsack Inc",
    "streetAddress": "758 Huel Neck",
    "addressLocality": "Hagenesstad",
    "addressRegion": "Illinois",
    "postalCode": "38421-3292",
    "addressCountry": "Tonga"
  }

[nissimsan]

@VladimirAlexiev , do you have any numbers on which address format has the highest adoption?

What would be the right choice, given our supply chain document focus?

[OR13]

There needs to be a lot of value to add more ways to represent location, I suggest closing unless these other systems have more adoption that schema.org / GS1... of their use case can't be made clear

[TallTed]

See Falsehoods Programmers Believe in about Geography among other things linked from that page

[nissimsan]

We are hesitant to include multiple address types. Anti-pattern. Not without really good reason anyway.