- From: Stéphane Corlosquet <scorlosquet@gmail.com>
- Date: Fri, 24 Jan 2014 11:30:16 -0500
- To: Matthias Tylkowski <matthias@binarypark.org>
- Cc: Thad Guidry <thadguidry@gmail.com>, Adrian Giurca <giurca@tu-cottbus.de>, Dan Brickley <danbri@google.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>, Libby Miller <libby@nicecupoftea.org>
- Message-ID: <CAGR+nnHuRAE9XhAJK34+Ok-P7Nzkj17_A=tk8g+WLv0DrkHMxg@mail.gmail.com>
On Fri, Jan 24, 2014 at 11:04 AM, Matthias Tylkowski < matthias@binarypark.org> wrote: > Maybe SocialAccount and Account in general is not the right direction > to go. Account data itself is usually private data and in a private place > (only visible for logged in people or admin). > No one (correct me if I'm wrong) would want to markup username and > password and what would be the benefit? > I don't think schema.org should limit itself to public data only (the data search engines can harvest). There are cases where it could be useful to model private account data with schema.org terms such as username and password hash in a private database. I'm not saying we should add these to this proposal, but simply that we should design this to be future proof and not be too restrictive. > In my View behind an Account is always a Person, either with real or fake > data, but in concept it is about a Person. > Some accounts could be shared and/or have an organization behind them. Some accounts could be used by a bot to perform operations or harvest data on a site requiring authentication. > > The Idea behind the SocialAccount proposal was to markup where a > information about one Person can be found. > "Look I'm on Twitter, LinkedIn and Facebook" > I think this can be modeled easily with the socialAccount property you are proposing, even if the type is Account (encompassing accounts held by real person, bots and all other use cases). Steph. > > Regards > Matthias > > -- > Technischer Leiter > Binarypark UG (haftungsbeschränkt) > Erich-Weinert-Str. 1 > 03046 Cottbus > Tel +49 (0)355 692931 > > Fax +49 (0)355 694171info@binarypark.orghttp://binarypark.org > > > Am 24.01.2014 15:53, schrieb Thad Guidry: > > Agreed, that a generic "Account" naming convention might be best to handle > 100% of all use cases from the highest level. > > I'd rather switch the semantics of "social" presence to just the 1960's > view of ... a "login presence". > > My personal definition of "Account" type would be defined as: > "An identifier for a login presence of a Person, Organization, or Thing > that represents them within a site or app" > (the key semantic difference in my definition is that it says it's an > "identifier for the presence" of a Person, Organization, Thing on a site or > app...and not necessarily the physical entity) > > The idea is further stretched into Drupal terms, (correct me if I'm > wrong, Stéphane) such as forums, etc, where "Account" is pseudo for "login" > or "login presence" that holds properties of "accountName" and "password", > etc. > > In machine terms, an "Account" is attached to a "login" typically, with > all it's relevant properties that are usually provided with an "Account" > type... username, password, full name, address, bank account #, account_id, > other_Accounts_on_the_web_that_you_want_to_link_to_this_Account, etc, etc, > etc. > > An "Account" 's username property is not necessarily their "identifier > for their presence", but typically is established in such a way nowadays. > (Login with your Facebook Account instead, blah, blah) > > -- > -Thad > +ThadGuidry <https://www.google.com/+ThadGuidry> > Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/> > > -- Steph.
Received on Friday, 24 January 2014 16:30:47 UTC