search

openreferral / specification

The Human Services Data Specification - a data exchange format developed by the Open Referral Initiative
https://openreferral.org
Other
117 stars 49 forks source link

Social media contacts for a service #220

Open MikeThacker1 opened 4 years ago

MikeThacker1 commented 4 years ago

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?

greggish commented 3 years ago

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.

klambacher commented 3 years ago

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).

MikeThacker1 commented 3 years ago

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?

klambacher commented 3 years ago

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

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

klambacher commented 3 years ago

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.

MikeThacker1 commented 3 years ago

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.

klambacher commented 3 years ago

Following up...

Our structure for the social media type list includes:

Data structure for community resources includes:

It's a customizable list, but drawing from one client's list I've got:

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.

pmackay commented 3 years ago

@MikeThacker1 I have a need for this too, would be interested to hear what the status is?

Cskyleryoung commented 2 years ago

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.

MikeThacker1 commented 2 years ago

Yes. We've been asked in the UK to add fields for social media.

It could be implemented by one of:

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.

Cskyleryoung commented 2 years ago

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: @.***>

MikeThacker1 commented 2 years ago

I think location was seen as a possible virtual location for a service as opposed to information about a service. They're slightly different.

Cskyleryoung commented 2 years ago

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: @.***>