4 ms·

> What benefits does NUM have over html over http? Web standards (JSON-LD, microdata, RDFa) are inefficient, since you have to download the entire HTML to find

> What benefits does NUM have over html over http? Web standards (JSON-LD, microdata, RDFa) are inefficient, since you have to download the entire HTML to find a particular piece of data like a phone number. Web standards are also not widely adopted enough for developers to build something on top of that data. For example, web standards can't be used to find a phone number for _any_ company with a phone number published to their website, since many small businesses don't mark up phone numbers with semantic web data. We're pre-populating NUM with millions of pieces of data so if a phone number is on the public website, it'll be in the NUM record for that domain. > One can use some semantic html tags to organize the data for parsing, making it roughly equivalent to NUM modules. Of course, the problem is that not enough websites do this (especially those of small business). > If a NUM client is running w/o a newly developed NUM module, how does it parse that data and how is it better than html without semantic meaning? If NUM is used for general purpose data storage (instead of for a particular module), then parsing of that data would need to be handled in a bespoke client – not a general purpose NUM client. Any advantages of using NUM over HTTP in this example but would be related to scaling and cost savings only.

lolinder 5y ago
> Web standards (JSON-LD, microdata, RDFa) are inefficient, since you have to download the entire HTML to find a particular piece of data like a phone number. You might have picked a bad demo project to show off the efficiency of NUM. It takes me 58 requests and (on my very fast connection) 5.3 seconds to download all the information for Barclays. Downloading a JSON blob with all the data for Barclays, parsing it, and displaying it, would take a fraction of the time. Sure, NUM might be great if you knew ahead of time exactly which DNS record the user would need, but most cases where something like this would be helpful I'd rather see a complete list of all contact information so I can make the correct choice given all the options. Are there use cases you've thought of where the application would know exactly which DNS record to load and display, rather than displaying an index the way you do with companydirectory.uk?
- elliottinvent 5y ago
  > You might have picked a bad demo project to show off the efficiency of NUM. It takes me 58 requests and (on my very fast connection) 5.3 seconds to download all the information for Barclays. That’s very slow, I’d be interested how much of the delay is from the DNS calls and how much is overhead from the demo site. We’ve purposely chosen to demo this site because it’s an example of an intensive NUM implementation. > Downloading a JSON blob with all the data for Barclays, parsing it, and displaying it, would take a fraction of the time. Of course, but that data doesn’t exist. Barclays’ phone numbers are split over hundreds of web pages which would require much more data download. I think your argument is that we could supply the data in JSON form, but then developers building on top of this data, would have to count out on our JSON response being fast and reliable. What we’re describing here is the current state-of-the-art, it’s an API model where developers usually pay to access that data. Barclays is a massive organisation with a very complicated contact setup. Smaller businesses are obviously much simpler, with all of their contact data contained within a single UDP packet of maybe 300 bytes.
  - lolinder 5y ago
    The 5.3 second figure is the time from the start of the first API call to the completion of the final API call, as shown in Firefox's Network tab.
    - elliottinvent 5y ago
      Very interesting, thanks for the data. “API call” being the first and last call to CloudFlare DoH? If so, there’s some throttling going on somewhere. It’s completing in around 1-1.5s for most I think.
      - laralamp 5y ago
        I tried a few companies on the site and only AXA was slow for me - it looks like there are 4s delays for many of the queries to _num.axa.co.uk, so maybe they have some throttling/DDoS protection going on. They return a SERVFAIL status code.
bfung 5y ago
Thinking about this a little more -- I'm not sure anyone is asking for something "more efficient" than html - at least in the USA, we're no longer bandwidth strapped. I thought the internet in UK was decent enough - at least when I visited in 2016 it was good enough to load google maps on 4G. For semantic parsing, probably went too far down semantic web tags. A simple "tel:" link works for most people and there's phone integration already. ex: <!DOCTYPE html> <title>My co</title> <a href="tel:123-456-7890">123-456-7890</a> (not well-formed, but it works!) - no js, no json required - good ole' html.
- elliottinvent 5y ago
  Thanks for coming back to this. Internet speeds in the UK are comparable with the US. Many parts of the world are not as fortunate, with bandwidth severely limited and extortionate data charges (unless it’s Facebook data, then it’s free?!). However, NUM doesn’t exist because the world has a bandwidth problem. You’re right of course that it’s possible to provide machine readable contact data on the web. NUM doesn’t exist because it’s not technically possible to do the same thing with data on the web. NUM exists because after 15 years of the semantic web, this data simply isn’t available for most businesses on the web. Even large businesses - take any example from the homepage of the demo site CompanyDirectory.uk, and see how they’ve implemented semweb standards. How they list their phone numbers for example. It’s an utter mess. Good luck to anyone trying to build a reliable service on top of that data.

lolinder 5y ago

> Web standards (JSON-LD, microdata, RDFa) are inefficient, since you have to download the entire HTML to find a particular piece of data like a phone number. You might have picked a bad demo project to show off the efficiency of NUM. It takes me 58 requests and (on my very fast connection) 5.3 seconds to download all the information for Barclays. Downloading a JSON blob with all the data for Barclays, parsing it, and displaying it, would take a fraction of the time. Sure, NUM might be great if you knew ahead of time exactly which DNS record the user would need, but most cases where something like this would be helpful I'd rather see a complete list of all contact information so I can make the correct choice given all the options. Are there use cases you've thought of where the application would know exactly which DNS record to load and display, rather than displaying an index the way you do with companydirectory.uk?

elliottinvent 5y ago
> You might have picked a bad demo project to show off the efficiency of NUM. It takes me 58 requests and (on my very fast connection) 5.3 seconds to download all the information for Barclays. That’s very slow, I’d be interested how much of the delay is from the DNS calls and how much is overhead from the demo site. We’ve purposely chosen to demo this site because it’s an example of an intensive NUM implementation. > Downloading a JSON blob with all the data for Barclays, parsing it, and displaying it, would take a fraction of the time. Of course, but that data doesn’t exist. Barclays’ phone numbers are split over hundreds of web pages which would require much more data download. I think your argument is that we could supply the data in JSON form, but then developers building on top of this data, would have to count out on our JSON response being fast and reliable. What we’re describing here is the current state-of-the-art, it’s an API model where developers usually pay to access that data. Barclays is a massive organisation with a very complicated contact setup. Smaller businesses are obviously much simpler, with all of their contact data contained within a single UDP packet of maybe 300 bytes.
- lolinder 5y ago
  The 5.3 second figure is the time from the start of the first API call to the completion of the final API call, as shown in Firefox's Network tab.
  - elliottinvent 5y ago
    Very interesting, thanks for the data. “API call” being the first and last call to CloudFlare DoH? If so, there’s some throttling going on somewhere. It’s completing in around 1-1.5s for most I think.
    - laralamp 5y ago
      I tried a few companies on the site and only AXA was slow for me - it looks like there are 4s delays for many of the queries to _num.axa.co.uk, so maybe they have some throttling/DDoS protection going on. They return a SERVFAIL status code.

bfung 5y ago

Thinking about this a little more -- I'm not sure anyone is asking for something "more efficient" than html - at least in the USA, we're no longer bandwidth strapped. I thought the internet in UK was decent enough - at least when I visited in 2016 it was good enough to load google maps on 4G. For semantic parsing, probably went too far down semantic web tags. A simple "tel:" link works for most people and there's phone integration already. ex: <!DOCTYPE html> <title>My co</title> <a href="tel:123-456-7890">123-456-7890</a> (not well-formed, but it works!) - no js, no json required - good ole' html.

elliottinvent 5y ago
Thanks for coming back to this. Internet speeds in the UK are comparable with the US. Many parts of the world are not as fortunate, with bandwidth severely limited and extortionate data charges (unless it’s Facebook data, then it’s free?!). However, NUM doesn’t exist because the world has a bandwidth problem. You’re right of course that it’s possible to provide machine readable contact data on the web. NUM doesn’t exist because it’s not technically possible to do the same thing with data on the web. NUM exists because after 15 years of the semantic web, this data simply isn’t available for most businesses on the web. Even large businesses - take any example from the homepage of the demo site CompanyDirectory.uk, and see how they’ve implemented semweb standards. How they list their phone numbers for example. It’s an utter mess. Good luck to anyone trying to build a reliable service on top of that data.