Re: Socialnetworks of a person or organization

In general abstract, There are "Feature -ery" things you can do on the
Social Web that involve "a communication pathway to an Organization or
Person"... that you cannot do with the Regular Web.  Some of that is now
even being semi-modeled with the Actions proposal.... and knowing which
URLs have a "communication" or "social pathway" will become an important
distinction...versus those that allow little to no communication to an
entity's presence on the web.

I hope that makes sense to everyone... I'm sure by now, we all understand
and know that we use Social Apps and Sites (Social Web) to engage and
"communicate"...versus merely reading (Regular Web).

The difference between the 2 is that one has the context of "allows a
communication pathway to an Organization or Person"...versus those that are
not constructed to really have communication to a Organization or Person".

In Freebase, we wanted to keep that important distinction...and so opted to
have a special property for Social Media Presence for any Thing (Topic in
Freebase) ... which also supports the idea of a URI Template, btw...kinda
cool to help with creating those parsing rules I mentioned before...
https://www.freebase.com/common/topic/social_media_presence?props=#/common/uri_property

Freebase only has the major Social Accounts in the URI Templates for
them...(Google+, Twitter, Foursquare, MySpace, etc) but as everyone
knows...there are now Thousands out there.

For marketers and advertisers, there is a difference in the 2...or any one
who cares...and I would refer to Aaron Bradley to discuss with the group
that particular subtle difference.



On Fri, Apr 11, 2014 at 2:56 PM, Justin Boyan <jaboyan@google.com> wrote:

> Thad,
>
> What is the difference between the Social Web and the Regular Web?
>
> Justin
>
> On Friday, April 11, 2014, Thad Guidry <thadguidry@gmail.com> wrote:
>
>> Justin brings up the point that he likes and wants to keep sameAs with
>> it's current definition of:
>>
>> 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.
>>
>> and extend that definition to also add , ", or official social accounts".
>>
>> Machine reading consumers (Data clients, Schema.org Stakeholders, Apps)
>> will then need to add more complex rules to determine "this is a
>> webpage.....or...this is a social account page".
>>
>> Again, I stand by my efforts to make the distinction between those 2
>> ideas/concepts with a new property.
>>
>> So a Web Developer who is building apps around Schema.org (he's a
>> consumer, just like the Stakeholders) has to know the difference between
>> those 2, a social account, and an reference Web page entity url (where an
>> entity url has no additional metadata about what KIND of entity it is until
>> you inspect it further).  He has to create parsing rules, etc...just like
>> the Stakeholders will need to do also.... because we decided to muddy the
>> waters and mix 2 different kind of Things... and lump them into 1... using
>> sameAs.
>>
>> I personally can make a quick leap in my brain to say... Oh this webpage
>> reference URL for DanBri is talking about the same entity as the twitter
>> account for DanBri...because my brain sees twitter/ ... but a computer has
>> to be taught that twitter/ is a social type of account prefix... and there
>> are THOUSANDS of those....so Data Consumers and Programmers will need to
>> write potentially Thousands of rules to determine if a sameAs link is part
>> of the Social Web or if it's part of the Regular Web, (probably not, but
>> you get the point)
>>
>> I want to automatically have Web Developers help the Stakeholders,
>> Machines, Apps, and Data Consumers....have to worry less and understand
>> more.  Immediately so.  By simply letting Web Developers do the HARD
>> WORK...which is really actually EASY for the Web Developers...since they
>> are the source of the data !
>>
>> Machines, Apps, Data Consumers, will not be making a "quick" leap...but
>> will have to apply additional rules to do so... and that, in this
>> case...will be a bad thing....they will be making the rules...instead of
>> letting the Web Developers (those little elves!!!) to do the damn easy work
>> for the Stakeholders, by giving those elves a nice hammer tool (a special
>> property) to fill in for "social accounts" versus "regular accounts" versus
>> "regular Web page reference entity URLs"
>>
>> The idea is to make thinks clear (for Machines, Apps, Data
>> Consumers)...and lumping reuse of sameAs will not provide distinction
>> between the Social Web and the Regular Web.
>>
>> Again, +1 for having a separate property to hold special consideration
>> for entities on the Social Web ... versus the Regular Web.
>>
>>
>>
>> On Fri, Apr 11, 2014 at 11:35 AM, Kingsley Idehen <kidehen@openlinksw.com
>> > wrote:
>>
>>  On 4/11/14 12:03 PM, Kingsley Idehen wrote:
>>
>> On 4/11/14 11:42 AM, Justin Boyan wrote:
>>
>> I'm going to +1 Dan's first post on this thread, where he suggested
>> reusing sameAs for this purpose and not introducing a new top-level
>> property.
>>
>>  sameAs already exists to allow linking to a reference page for an
>> entity, like its Wikipedia page, Freebase page, or website (DNS registry
>> page). The social sites motivating the 'hasAccount' proposal -- Facebook,
>> Twitter, G+, LinkedIn, etc. -- can equally be viewed as catalogs of
>> entities. The issue of who controls the data for that entity on the site is
>> a slippery issue that wouldn't be captured in the account vs. sameAs
>> distinction anyway.
>>
>>  In fact, sameAs is actually clearer semantically than 'hasAccount':  an
>> organization like the BBC with many Twitter accounts might be tempted to
>> list all of them under 'hasAccount', whereas sameAs more clearly limits the
>> desired link to just the top-level account for the BBC as a whole. (Twitter
>> accounts for suborganizations of the BBC would be better modeled via sameAs
>> links from entities corresponding to those suborganizations.)
>>
>>  I don't see any particular semantic gain from { BBC hasAccount
>> twitter.com/BBC } compared to { BBC sameAs twitter.com/BBC }.
>>
>>  Whereas, I'm concerned that webmasters will become ever more confused
>> when they have to worry about hasAccount alongside the existing sameAs,
>> url, and @id on every single schema.org type.
>>
>>  My $0.02.
>> Justin
>>
>> Justin,
>>
>> I assumed "account" and my suggested "hasAccount" denoted actual "account
>> ownership" oriented relations i.e., relationship properties that determine
>> how two entities are associated. In short, my entry into this thread was
>> all to do with providing counter points to some arguments about unambiguous
>> vs ambiguous entity denotation, using HTTP URIs.
>>
>> Of course I wouldn't be suggesting "account" or "hasAccount" as
>> identifiers for coreference relations.
>>
>> 'same as', 'sameAs', :sameAs, <http://www.w3.org/2002/07/owl#sameAs><http://www.w3.org/2002/07/owl#sameAs>,
>> are different kinds of identifiers that denote age-old coreference
>> relations. The only issue is whether inference and reasoning on these
>> relations is scoped to:
>>
>> 1. humans
>> 2. machines
>> 3. both.
>>
>> Hope this clarifies my position :-)
>>
>>
>> Just to close the loop re., comments above. Here is a more readable link
>> to a document that describes the owl:sameAs relation [1].
>>
>> [1]
>> http://linkeddata.uriburner.com/about/html/http/www.w3.org/2002/07/owl%01sameAs
>> -- owl:sameAs relation
>> [2]
>> http://linkeddata.uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2F2002%2F07%2Fowl%23sameAs&graph=http%3A%2F%2Fwww.w3.org%2F2002%2F07%2Fowl-- ditto but with faceted navigation over relations, as an interaction
>> option .
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen	
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profil
>>
>> --
>> -Thad
>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>> Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
>>
>


-- 
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>