W3C home > Mailing lists > Public > public-vocabs@w3.org > January 2014

Re: Socialnetworks of a person or organization

From: Adrian Giurca <giurca@tu-cottbus.de>
Date: Fri, 24 Jan 2014 13:06:44 +0100
Message-ID: <52E25754.7040607@tu-cottbus.de>
To: Dan Brickley <danbri@google.com>
CC: Thad Guidry <thadguidry@gmail.com>, Stéphane Corlosquet <scorlosquet@gmail.com>, Matthias Tylkowski <matthias@binarypark.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>, Libby Miller <libby@nicecupoftea.org>
On 1/24/2014 12:36 PM, Dan Brickley wrote:
> On 24 January 2014 09:34, Adrian Giurca <giurca@tu-cottbus.de> wrote:
>> Dear Dan,
>> Before being "follow" use case the capability to represent the social
>> presence of a Person or Organization is a simple knowledge representation
>> problem.
>> The main use case is that million of web sites  shows of their first page
>> their social presence by linking to their respective social accounts.
>> Therefore we proposed two ways to encode this:
>> 1. let http://schema.org/socialAccount be a property expecting a URL as
>> value. Let update http://schema.org/Person and
>> http://schema.org/Organization with this property. Then
>>   webmasters would represent immediately what they look for, e.g.,
>> <a itemprop="socialAccount" href="http://twitter.com/johndoe"
>> class="icon-twitter">Follow Me on Twitter</a>
>> <a itemprop="socialAccount" href="http://facebook.com/cocacola"
>> class="icon-facebook">Facebook</a>
>> ...
>> 2. Let http://schema.org/SocialAccount be a type and
>> http://schema.org/socialAccount be a property expecting URL or
>> http://schema.org/SocialAccount as value. Then some, more experienced,
>> webmasters would take advantage of the http://schema.org/SocialAccount
>> properties inherited from http://schema.org/Thing.
> So this is more or less the design FOAF settled on, with foaf:account
> and :OnlineAccount.
> In a schema.org-in-2014 setting, there are some natural questions:
> What can be done with 'socialAccount' that we can't already do with
> the 'url' and 'sameAs' properties?
Should a webmaster use

<a itemprop="url" href="http://twitter.com/johndoe"
class="icon-twitter">Follow Me on Twitter</a>
<a itemprop="url" href="http://facebook.com/cocacola"

http://schema.org/Thing introduce http://schema.org/url as "URL of the item". Therefore If I have a page describing an Organization then I would expect to use this property with the value the page's URL...
<a itemprop="sameAs" href="http://twitter.com/johndoe"
class="icon-twitter">Follow Me on Twitter</a>
<a itemprop="sameAs" href="http://facebook.com/cocacola"

sameAs is  described as "URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Freebase page, or official website."

So, I guess sameUs was introduced to solve the never ending problem of 
identity. Some web sites such as Wikipedia or Freebase would be a kind 
of identity providers. But as an organization I may have many Facebook 
pages (just to give an example). Do these pages unambiguously define my 
identity? Possibly, I don't know for sure.

> What do we get from saying "this is a _social_ account"?  What kinds
> of non-social account pages are excluded? What kinds of social but
> non-account pages are excluded? Is an account/profile LinkedIn
> primarily "social"? Flickr? someone's YouTube channel? a private
> profile page on a closed site? Someone's homepage, blog or microblog,
> selfhosted or hosted? Their MediaWiki e.g. Wikipedia user page? Public
> bookmarks on pinboard.in? a Web page by some person? about that
> person? Publicly editable by everyone including that person? And
> FTP-able hosted (and public?) folder that the user can post arbitrary
> content to? A page that contains content verified to have been
> created/edited/checked by the person it describes, where that person
> authenticated themselves using a different site?
I dis not considered any restriction on which links webmaster would use 
socialAccount... Each web site should have its own policy on which pages 
want to declare as being its social presence.
> The Web (and Internet) has always been social (c.f.
> http://www.w3.org/Talks/Informing.ps‎ from 20+ years ago, excuse the
> PostScript file format ), and Web sites (individually and as a whole
> over the years) evolve fast. I'm not sure it is so easy to determine
> which sites and services count as social, and which pages as social
> accounts. So I lean towards trying to define just 'account', which
> might be hard enough. I have some ideas but I'd rather listen for
> now...
I am an adept of free market such that I don't want to tell anyone what 
should be social and what should not be. Maybe your proposal to define 
Account is better. In the end is just a matter of name.
>> Therefore, I see two issues here:
>> a) If there is another better representation solution
>> b) If there are enough use cases to describe social presence of an entity.
> Yes, it's a reasonable design sketch for discussion.
> cheers,
> Dan
All the best,
>> Sincerey yours,
>> Adrian Giurca
>> On 1/23/2014 10:11 PM, Dan Brickley wrote:
>> +Cc: Libby
>> On 23 January 2014 14:55, Charles McCathie Nevile <chaals@yandex-team.ru>
>> wrote:
>> On Wed, 22 Jan 2014 16:19:05 +0100, Stéphane Corlosquet
>> <scorlosquet@gmail.com> wrote:
>> +1 for some form of account type. What about UserAccount? SocialAccount
>> sounds a bit specific, in the sense that some accounts might not be
>> "social" but more like administrative (e.g. admin account). IMO
>> UserAccount is more generic and can account for both human / social
>> people, and also inanimate and/or fictional agents.
>> Hmm. I think of this slightly differently and think maybe we should model it
>> as Things (people mostly) being memberOf groups - and potentially also being
>> author of or contributor to content (e.g. a social network feed of some
>> kind).
>> There are people who are *part* of an "account", and who have multiple
>> presence in the same system - and more so for organisations.
>> But I'm only at the beginning of thinking this through.
>> It is a truth universally acknowledged, that this stuff is quite fiddly.
>> I can recap some experience from the FOAF project. We added an
>> OnlineAccount type there back ~ 2003,
>> http://lists.foaf-project.org/pipermail/foaf-dev/2003-July/005588.html
>>    For OnlineAccount, http://xmlns.com/foaf/0.1/#term_OnlineAccount ...
>> plus a few properties.
>> The original name for the relationship between a Person (or foaf:Agent
>> e.g. foaf:Organization, foaf:Group) and their OnlineAccount(s) was
>> "holdsAccount". At some post-RDFa point we then aliased that to the
>> simpler name "account", and explored the idea that the identifier of
>> the instances of OnlineAccount would in most cases be an account page
>> on some site, which is also more or less what XFN does. The subtypes
>> of OnlineAccount were never used much afaik.
>> Looking back with retrospecs, just having a simple URL to an account
>> page e.g. http://twitter.com/danbri covers a lot. But breaking out
>> things like "the username associated with this account" can be useful
>> too. Another design is to have a kind of indirection and be describing
>> something like an addressbook entry in a package (vCard / PoCo
>> portablecontacts.net/draft-spec.html etc.) as distinct from the
>> general properties of the person/agent that hold it. Worth noting that
>> PoCo also has a simple 'account' construct, essentially a top level
>> domain + username + userid. This is basically the same model as FOAF's
>> OnlineAccount, which has accountName and accountServiceHomepage.
>> While you can do a lot of interesting things with a "Group"
>> construction (e.g. lists / circles, ...) I'm not sure yet about using
>> Group for accounts.
>> The general issue with all this is the need to flip/flop between
>> account-oriented and person-oriented information in quite a fluid way.
>> Sometimes you'll want to say "Dan knows Charles", other times that
>> https://twitter.com/danbri follows https://twitter.com/chaals; but to
>> always be providing information at both levels  can be painfully
>> verbose.
>> Stéphane - is this a concrete / practical issue for the Drupal
>> schema.org representation? If there are use cases and examples to
>> guide the discussion that would be very useful.
>> Dan
Received on Friday, 24 January 2014 12:07:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:21 UTC