- From: Justin Boyan <jaboyan@google.com>
- Date: Fri, 11 Apr 2014 15:56:18 -0400
- To: Thad Guidry <thadguidry@gmail.com>
- Cc: "public-vocabs@w3.org" <public-vocabs@w3.org>
- Message-ID: <CABJSzUtXg-0t2=WwP1sXpn+NoiZ5KTy7MLzSrNv3HK5AfPjqxA@mail.gmail.com>
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/> >
Received on Friday, 11 April 2014 19:56:47 UTC