Re: best practice to represent social media accounts for org like Fire departments, Police, etc.

tempted to suggest:
add <persona>

On Wed, Apr 3, 2024 at 10:58 PM Richard Wallis <
richard.wallis@dataliberate.com> wrote:

> Using the *PropertyValue* pattern for *identifier *might work here.
> Especially if applied to a *ContactPoint*.
>
>  @prefix s: <http://schema.org/> .
>
>
>  <http://anorg.com> a s:Organization ;
>   s:address "1 A Street, London" ;
>   s:contactPoint [
>     a s:ContactPoint ;
>     s:identifier [
>       a s:PropertyValue ;
>       s:propertyID "Telegram ID" ;
>       s:value "OrgTelID"
>     ] ;
>     s:name "Telegram Account"
>   ] ;
>   s:name "An Organization”.
>
>
> ~Richard
>
>
>
>
> On 3 Apr 2024 at 14:41:39, Ryan Levering <rrlevering@google.com> wrote:
>
>> Yeah, I guess technically that would be extra information on
>> the relationship between the Organization and the UserAccount, but
>> schema.org isn't that normalized usually.  You could use Role (*small
>> shudder*).
>>
>> It would be totally fine to add more properties.  I personally need the
>> type for creation/deletion dates/status on the accounts.  There's just no
>> abstraction for the concept to hang any of these ideas.  Maybe it could be
>> a description or category or something new.
>>
>> I was just using that URI as a local identifier.  It could be a blank
>> node with just a provider that uniquely identified it.
>>
>> On Wed, Apr 3, 2024 at 9:31 AM Arnaud Sahuguet <arnaud.sahuguet@gmail.com>
>> wrote:
>>
>>> Thank you Ryan.
>>>
>>> Two comments:
>>> 1. FDNY has multiple Twitter accounts, e.g. general announcements,
>>> careers, etc.
>>> I would need UserAccount to have an extra property to define the purpose
>>> of the account.
>>> 2. For messaging apps like Signal, Telegram with no Web interface (as
>>> far as I know), there is no Web URI to use as an identifier. How would you
>>> solve the issue?
>>>
>>> Arnaud
>>>
>>> On Wed, Apr 3, 2024 at 9:26 AM Ryan Levering <rrlevering@google.com>
>>> wrote:
>>>
>>>> My proposal is to have a UserAccount type that has edges to
>>>> Person/Organization: https://github.com/schemaorg/schemaorg/issues/3403
>>>>
>>>> @prefix s: <http://schema.org/> .
>>>> <https://www.nyc.gov/site/fdny/> a s:Organization ;
>>>>   s:hasAccount <https://twitter.com/FDNY> ;
>>>>   s:hasAccount <https://www.facebook.com/FDNY> .
>>>>
>>>> <https://twitter.com/FDNY> a s:UserAccount ;
>>>>   s:name "FDNY"
>>>>     s:provider <https://twitter.com>
>>>>
>>>> IMO, ContactPoint is not quite the right direction because it's
>>>> provider-agnostic (a phone number or email is thankfully a global
>>>> address).  The UserAccount is only relevant in the context of the place
>>>> where the account is.
>>>>
>>>> But for your specific case, at Google we currently interpret sameAs in
>>>> the way you use in the example.  That's the only way we have to represent
>>>> it in our systems.
>>>>
>>>>
>>>>
>>>> On Wed, Apr 3, 2024 at 9:14 AM Arnaud Sahuguet <
>>>> arnaud.sahuguet@gmail.com> wrote:
>>>>
>>>>> Thank you, Dan.
>>>>> It is nice to cross paths again (we collaborated on
>>>>> https://schema.org/GovernmentService when I was at Google.org).
>>>>>
>>>>> Wikidata is going very deep with one property per social media
>>>>> "entity", e.g. https://www.wikidata.org/wiki/Property:P2397 for
>>>>> YouTube. This can open a can of worms: what defines a social media entity,
>>>>> who is worthy of such a property, why is my social media website not in the
>>>>> list, etc.?
>>>>>
>>>>> I am wearing my "civic data lenses", with a focus on city and
>>>>> government services.
>>>>> I would like to be able to list all their social media accounts and
>>>>> for what purpose they use them.
>>>>>
>>>>> I would argue that social media is a form of ContactPoint. The
>>>>> current version of ContactPoint was designed pre-social media.
>>>>>
>>>>> Supporting social media *and* messaging apps (e.g. signal, telegram,
>>>>> etc.) would be super relevant.
>>>>>
>>>>> 1. Most social media have a web interface: having a url should be
>>>>> enough and we get it for free from Thing.
>>>>> 2. For messaging apps, we need to capture the user handle/id but also
>>>>> the name of the app.
>>>>> Maybe having a new DigitalContactPoint schema (parent == ContactPoint
>>>>> ??) with a new property called userid to capture the user account.
>>>>>
>>>>> In the meantime, what would you recommend for my FDNY example?
>>>>> The issue I have with sameAs is that I cannot capture the fact that
>>>>> FDNY has multiple channels, one for casual announcements, one for critical
>>>>> announcements, etc.
>>>>> ContactPoint is a bit of an overkill and does not convey the fact
>>>>> that this is a social media account.
>>>>>
>>>>> regards,
>>>>>
>>>>> Arnaud
>>>>>
>>>>> On Wed, Apr 3, 2024 at 5:07 AM Dan Brickley <danbri@google.com> wrote:
>>>>>
>>>>>> +Ryan
>>>>>>
>>>>>> I have discussed the idea of modeling accounts with Ryan (cc:d) from
>>>>>> time to time. It could be useful but as ever it is hard to know how deep to
>>>>>> go.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> On Tue, 2 Apr 2024 at 22:04, Arnaud Sahuguet <
>>>>>> arnaud.sahuguet@gmail.com> wrote:
>>>>>>
>>>>>>> I am trying to represent the various media accounts using by New
>>>>>>> York City fire department. The list is at
>>>>>>> https://www.nyc.gov/site/fdny/connect/social-media/social-media.page
>>>>>>> .
>>>>>>>
>>>>>>> If I want to attach the Twitter/X account and Facebook account of
>>>>>>> FDNY, I could do
>>>>>>> @prefix s: <http://schema.org/> .
>>>>>>> <https://www.nyc.gov/site/fdny/> a s:Organization ;
>>>>>>>   s:sameAs <https://twitter.com/FDNY> ;
>>>>>>>   s:sameAs <https://www.facebook.com/FDNY> .
>>>>>>>
>>>>>>> Is there a better way that conveys the fact these accounts are
>>>>>>> social media accounts?
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> --
>>>>>>> Arnaud
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Arnaud Sahuguet
>>>>>
>>>>>
>>>
>>> --
>>> Arnaud Sahuguet
>>>
>>>
>
> --
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis
> Twitter: @dataliberate @rjw
>
>

Received on Thursday, 4 April 2024 04:48:29 UTC