Address lines

[VladimirAlexiev]

Address: the breakdown lineOne, lineTwo, lineThree, lineFour is

• pretty random: why not 6 or 10?
  • Dun & Bradstreet data has StreetAddressLine1..4 in one case, but MailingLabelLine1..8 in another case. How do you squeeze 8 DnB lines into the uncefact lines?
• old-fashioned: xsd:string allows multiple lines
• doesn't match popular address ontologies: schema.org, W3C LOCN, FIBO (https://github.com/edmcouncil/fibo/issues/237)

So merge to just one prop eg addressLines.

This is low priority since it contradicts the desire to map UNCEFACT models as-is.

[Fak3]

More broader edi3 discussion: https://github.com/edi3/edi3-json-ld-ndr/issues/7

[onthebreeze]

It might be time for a discussion about whether UNECE should continue to promote its own version of basic things like address or whether it should recognise other standards like schema.org that, at least for those terms, are vastly more widely adopted.

One solution to this is to build UN supply chain semantics as extensions on more foundational stuff like schema.org ?

[nissimsan]

Agreed 100%, the world needs less - not more - definitions of what an address is.

It's not low priority, though; I see this as an important part of our job, making decisions like this to facilitate semantic interoperability with the broader world.

@VladimirAlexiev, I'd be interested in your opinion, is https://schema.org/PostalAddress the most suitable choice for trade and transport use cases?

[nissimsan]

Pondering how we would concretely do this? I suppose remove https://service.unece.org/trade/uncefact/vocabulary/uncefact/#Address and its elements, and replace all references to it to instead reference https://schema.org/PostalAddress? Thoughts?

[VladimirAlexiev]

uncefact:Address has a bunch of attribs that schema:PostalAddress doesn't (all xsd:string except as indicated:

additionalStreetName
attentionOf
buildingName
buildingNumber
careOf
cityId  xsd:token
cityName
citySubDivisionName
countryId   xsd:token
countryName
countrySubDivisionId    xsd:token
countrySubDivisionName
departmentName
identificationId    xsd:token
lineFive
lineFour
lineOne
lineThree
lineTwo
postOfficeBox
postcodeCode
streetName
typeCode

I see normalization issues with some of them (#68), but that's not sufficient reason to throw this class away.