specification
specification copied to clipboard
openreferral
Social media contacts for a service
I have UK implementers saying they need to record Twitter, Facebook, Instagram etc handles for services.
How do people do that?
Does it need an extension to the standard or does it fit in to what we have now?
Good question. It seems reasonable, but i don't think we've addressed it before. I wonder whether this would necessarily be for an organization, or at the service level... or whether it would have to be linkable to either.
We have a social media contact type that includes the name of the social media type (Twitter, FB, Insta, etc.) and the URL and protocol. They social media types are drawn from a fixed list which includes meta information. It is absolutely the case that there are unique SM account for both the Agency and the specific services, so I'd recommend that this be available at both levels, though service would be the only absolute requirement (i.e. don't do just the Agency level).
That's really useful @klambacher Can you advise what field(s) your using (or adding) in what table(s) in the HSDS structure? Also, do you have an encoded list of social media types?
We've got a bit more complex structure than the HSDS so it's not directly adaptable, but the social media structure connects to any of Service / Site / Agency (Site is likely irrelevant in the real world, but it's allowed in our model).
The structure for us is
- Base Record connects to Social Media Core data (basic link of Base Record ID and SM code/ID)
- Social Media Core data connects to list of Social Media Types (includes Meta data such as SM "code" (language and system agnostic), icons, etc.)
- Social Media Types connect to Social Media Language specific (includes SM names in applicable languages)
- Social Media Core data connects to Social Media language-specific (includes URL)
This is likely more complex than needed in the general case, in part because our records are multilingual.
The basic needs at the meta-data level are:
-> Social Media code or transportable identifier that allows consistent sharing between systems -> Name of the Social Media type
The basic needs at the record level are: -> 1:many association between base record and social media contacts -> related entry references social media type -> related entry references specific URL and protocol for the record contact
Also, we haven't previously published the list of SM types and codes but happy to do so. I'll get that up for you in https://github.com/OpenCIOC/communityinfoclassifications if that's helpful. I really need to update those lists anyway.
Gulp. Thanks @klambacher.
I'll need to come up with a way of extending the formal HSDS structure and will probably exclude different languages. I'll throw this back at the users to see if they want/need to associate social media contacts with just services or also organizations and locations.
A common list of SM types for use by us all as a simple taxonomy or encoded list would be good.
Following up...
Our structure for the social media type list includes:
- language-agnostic name/code (for import / export purposes) *required
- language-specific name *optional
- icon URLs (16px/24px) *optional
- URL of Social Media base website *optional
Data structure for community resources includes:
- reference to social media type entry *required
- language-specific URL to the page / site for the community resource *optional
It's a customizable list, but drawing from one client's list I've got:
- YouTube
- Yelp
- Meetup
- WordPress
- Discord
- Flickr
- Vimeo
- PodCast (this is generic - no specific SM provider)
- RSS (this is generic - no specific SM provider)
- Blogger
- Tumblr
I'm kind of surprised TikTok isn't on that list yet.
What you'll probably notice most about this list is that it is publishing platforms, not messaging apps. If you want to encompass messaging platforms, this data structure may not work as well.
@MikeThacker1 I have a need for this too, would be interested to hear what the status is?
I've been wondering why the url service field isn't normalized in exactly the same way phone is. That would allow one-to-many relationships with service, organization and more, and would include an enumerated type field, which in this case would probably be "website", "facebook", "twitter", and all the rest.
Yes. We've been asked in the UK to add fields for social media.
It could be implemented by one of:
- specific fields in
service - a new table called something like
reference_informationwith the enumeratedtypefield you suggest -
service_attributeswith a newvaluefield in which the url is given
However, there is an argument that service.url is the main URL of the service which could be a web page, Facebook page or whatever and any other links should be obtained via that main URL.
Does that last use case overlap with using location for virtual resources?
On Tue, Feb 22, 2022 at 4:09 AM MikeThacker1 @.***> wrote:
Yes. We've been asked in the UK to add fields for social media https://forum.openreferraluk.org/t/enhancements-to-or-uk-proposal-to-add-more-urls-for-social-media-guidance-and-other-information-per-service/124 .
It could be implemented by one of:
- specific fields in service
- a new table called something like reference_information with the enumerated type field you suggest
- service_attributes with a new value field in which the url is given
However, there is an argument that service.url is the main URL of the service which could be a web page, Facebook page or whatever and any other links should be obtained via that main URL.
— Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/220#issuecomment-1047630713, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYZRPKA73E2SPC6OSPNWE3U4NOGPANCNFSM4SBTOKDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
I think location was seen as a possible virtual location for a service as opposed to information about a service. They're slightly different.
I guess I can see that in the context of Metaverse and similar realms. Thanks for the clarification.
On Tue, Feb 22, 2022 at 11:42 AM MikeThacker1 @.***> wrote:
I think location was seen as a possible virtual location for a service as opposed to information about a service. They're slightly different.
— Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/220#issuecomment-1048051158, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYZRPNRURJN53UHDZMYC5LU4PDJRANCNFSM4SBTOKDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>