We need a normalized `url` table in the pattern of the `phone` table

Technical
1

I’ve imagined this scenario would arise for a while now, and it just did. One of our clients has multiple URLs per service record. For example website, Facebook, and more. They are ruminating on adding text formatting into the single URL field such as:

Facebook: https://facebook.com/abc, Website: https://abc.org

I, of course, am trying to avoid that at all cost.

I’m also avoiding using attribute as it doesn’t provide enough context. In the above, I need to know at least two things about each URL value:

  1. That it is a URL
  2. What it’s for (a label like Facebook).

At present all I can add in attribute is the value, ie https://facebook.com/abc, with no context on what it is or what to do with it.

We considered adding multiple virtual locations, but that feels like a cumbersome use of the location table, and will obfuscate locations that are truly virtual. I don’t want to generate a service_at_location record for Facebook, unless Facebook happens to be the primary point of service for something. In most cases, it is not.

The most obvious solution is to normalize URLs into their own table. I would almost exactly follow the pattern of the phone table, allowing URLs to be linked to organization, service, location, service_at_location, perhaps even contact.

Is this is a necessary step? Have you found other workarounds for handing multiple URLs on an entity?

@bloom @MikeThacker @PollyM @devin

2

I think attributes can work for this where either link_entity or taxonomy_term is used as the label.

I’ve been a long time proponent of adding an additional “description:” field to the attributes table to make it even more useful for use cases like the one you describe here and many others.

3

This GitHub issue may be a relevant thread for reference?

4

@devin I agree wholeheartedly that attribute would be much more useful with a description field included.

@bloom thanks for the reference. I forgot that I was involved in that Github issues thread as well. I don’t see any recent activity there though. It does seem like a normalized table would be generally well received, based on that thread. What’s it take to promote that recommendation?

5

Go forth and shape it up here, then maybe bring it back there. of course you can make a pull request any time, but it will be easier (especially when we are not in standard development mode) to get consensus in discussion around it.

6

I can’t name implementations that have come across this although @Ian-DigitalGaps may be able to.

My first reaction was to add multiple virtual locations but attributes may well be better, even if you have to add a description field which profiling would allow.

In general, I think we should encourage attributes for extensions but periodically review how attributes are used to see if there’s a case for amending HSDS.