Address lines about spec-jsonld HOT 5 CLOSED

More broader edi3 discussion: edi3/edi3-json-ld-ndr#7

from spec-jsonld.

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 ?

from spec-jsonld.

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?

from spec-jsonld.

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?

from spec-jsonld.

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.

from spec-jsonld.