Beckn Location Schema Enhancement Proposal

[emmayank]

Hello, Beckn community,

I hope this message finds you well. I am writing to propose an update to the Beckn Location Schema to incorporate a new feature—Digital Location. As our ecosystem evolves, it's crucial to adapt our standards to meet the emerging needs of the users and developers.

Objective:

The objective of this proposal is to enhance the Beckn Location Schema to include a standardized representation of Digital Location. Digital Location refers to the concept of specifying a digital address or identifier for locations, broadening the spectrum of use cases for our ecosystem.

Motivation:

As the digital landscape advances, there's a growing demand for precise and standardized ways to represent digital addresses alongside physical addresses. This update would provide a foundation for applications and services that rely on digital locations, offering flexibility and efficiency.

Proposed Changes:

Introduction of Digital Location Object:

A new object within the Beckn Location Schema will be introduced to encapsulate digital location details.
Attributes for Digital Location:

Location:
      description: The physical location of something
      type: object
      properties:
        id:
          type: string
        descriptor:
          $ref: '#/components/schemas/Descriptor'
        map_url:
          description: The url to the map of the location. This can be a globally recognized map url or the one specified by the network policy.
          type: string
          format: URI
        ...
        ...
        ...
        digital_address:
          $ref: '#/components/schemas/digital_address'

digital_address:
      description :  The Digital Location of something
      type: object
      properties:
        web_url:
          type: string
          description : Uniform Resource Locators
          example: "https://www.example.com/page/index.html"
        ip_address: 
          type: string
          description : "Internet Protocol Addresses. Identify and locate devices on a network."
          example : "192.168.1.1"
        mac_address: 
          type: string
          description : "Uniquely identify network interfaces for communication on a local network."
          example : "00:1A:2B:3C:4D:5E"
        email_address: 
          type: string
          description : "Identify individuals for sending and receiving emails."
          example : "user@example.com"
        uri:
          type: string
          description: "Identify resources, encompassing both URLs and URNs."
          example: "urn:isbn:0451450523"
        urn: 
          type: string
          description : "Identify resources by name in a namespace, intended to be persistent and location-independent."
          example: "urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66"
        ftp_address: 
          type: string
          description: "Specify the location of files on a remote server for file transfer."
          example: "ftp://username:password@ftp.example.com/public/documents/file.txt"
        bluetooth_address: 
          type: string
          description: "Identify Bluetooth devices for communication and connection."
          example: "AC:23:3F:45:6B:89"

Improved Use Cases:

Support a broader range of use cases, such as 'location of some provider may be digital', 'digital address for a fulfillment type', and virtual experiences.

Next Steps:

If there's a consensus in favor of this proposal, we can outline a roadmap for implementation, assign responsibilities, and set a timeline for the release.

Thank you for your attention, and I look forward to a productive discussion.

Best regards,
Mayank Bansal
@emmayank

[emmayank]

@ravi-prakash-v @venkatramanm Please share your thoughts on this

[venkatramanm]

May be digital address with generic fields like

protocol(enum http,ftp,blue
..)
uri
parameters

may be enough.

Not sure if attributes are needed by each protocol. Like web_url,ftp_url etc.

Or may be just have digital address as a string whicb would have an appropriate value with a complete uri scheme..

[venkatramanm]

Also we could have multiple digital addresses by different protocols.
E.g fulfillment end location could be a http url or an FTP url ?

Thinking aloud .

Could have an array of digital addresses. It cannot be captured as array of locations @emmayank , as there would be only one fulfillment end location.

[amarts]

Thanks for bringing this up. This makes sense, and also would allow already existing concept of "cloud kitchen" type of businesses to have complete digital address.

My comment is only on the spec of the 'digital_location'. no amount of specific endpoints (ip addr, web url, ftp, bluetooth etc) would suffice and one may come back with asking for one more endpoint as they are a digital platform of users.

That is why I propose to use a DID as digital identity. This allows one to prove the address digitally (as it has public key, and one can prove it with their private key, and also the spec allows defining multiple services which can be updated by individuals as they wish.

[rajaneeshk90]

The suggestion is valid.

In my view, including web_url, uri, and urn may be unnecessary. While URIs and URNs are adept at identifying internet resources, they lack specific location information.

In contrast, a URL not only identifies a resource but also pinpoints its location on the internet. Furthermore, a URL includes a protocol field specifying how to access the resource, as seen in examples like:

ftp://ftp.example.com/files/doc.pdf
https://www.example.com/index.html
telnet://example.com:23
Hence, relying solely on the URL should suffice.

I agree with Amart's suggestion that developers might introduce various other endpoint types. Depending on specific endpoints may not provide a sustainable solution. Instead, we should aim for a more generic approach.