Re: Socialnetworks of a person or organization

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+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>


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