W3C home > Mailing lists > Public > public-vocabs@w3.org > August 2013

Re: LocalBusinessDepartment proposal for schema.org.

From: Thad Guidry <thadguidry@gmail.com>
Date: Fri, 30 Aug 2013 22:17:54 -0500
Message-ID: <CAChbWaOyVRr-eoBNBzNX0i3hL4CzZMY1zzgtjPGUrs13DOmtpg@mail.gmail.com>
To: Justin Boyan <jaboyan@google.com>
Cc: Martin Hepp <martin.hepp@ebusiness-unibw.org>, James McKinney <james@slashpoundbang.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
No Justin,

I would hope and like to think that LocalBusinessDepartment would be a
"more specific type" under LocalBusiness.  Not a top-level Thing like we
have for Organization.

It would look like this:

Thing > Organization > LocalBusiness > LocalBusinessDepartment

We would Reuse and Recycle existing properties (where Martin is saying
"expand the domain of an existing property").

The bottom line and what we are pitching out there for everyone to realize
moving forward ...

is that Schema.org needs to carefully orchestrate and create more specific
Types to reach broader domains (and the long tail domains), while expanding
the domain usage of existing properties (with good and better descriptions)
we already have in place.  And avoiding shoving 50+ properties under a Type
that does not really even conceptually represent a good placeholder for all
those 50+ properties.  If your going to make generic properties then the
Type holding them has to be fairly generic as well.

For Schema.org, there is only really one Type that comes close to being
generic... a Thing.  And no one would vote for 8000+ properties under
Thing. :-)

Hope that makes sense.
-- 
-Thad
Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>

On Fri, Aug 30, 2013 at 4:01 PM, Justin Boyan <jaboyan@google.com> wrote:

> Thad and Martin,
>
> Are you proposing that the new type (LocalBusinessDepartment) would not be
> a subtype of LocalBusiness at all, but a new top-level Thing with only
> contactPoint, openingHours, and departmentOf properties?
>
> That certainly would be nice and simple, and meet the needs of the
> immediate use case.
>
> I'm wary of trying to model over-generically all forms of organizational
> divisions. LocalBusinessDepartment.departmentOf and the existing
> LocalBusiness.branchOf are quite specific and clear.
>
> Justin
>
>
>
>
>
> On Wed, Aug 28, 2013 at 10:12 AM, Martin Hepp <
> martin.hepp@ebusiness-unibw.org> wrote:
>
>>
>> On Aug 28, 2013, at 3:54 PM, Thad Guidry wrote:
>> ...
>> >
>> > 3. Borrow the property for contactPoint from Organization.
>> >
>> > Reduce, Reuse, Recycle... we should be heavy on the Reuse / Recycle of
>> properties, and less so on the Reduce (promotion), since Reduce causes more
>> confusion than worth, typically.
>> > .
>>
>> I agree. In many cases, it is better to expand the domain of an existing
>> property than to define a common super-type.
>>
>> This is also important since otherwise Web developers are flooded with
>> properties for a given type. See the many properties that
>>
>>     http://schema.org/WebPage
>>
>> inherits from
>>
>>     http://schema.org/CreativeWork
>>
>> Many of them are conceptually valid yet practically not applicable to
>> many Web pages.
>>
>> Martin
>>
>>
>> > --
>> > -Thad
>> > Thad on Freebase.com
>> > Thad on LinkedIn
>>
>> --------------------------------------------------------
>> martin hepp
>> e-business & web science research group
>> universitaet der bundeswehr muenchen
>>
>> e-mail:  hepp@ebusiness-unibw.org
>> phone:   +49-(0)89-6004-4217
>> fax:     +49-(0)89-6004-4620
>> www:     http://www.unibw.de/ebusiness/ (group)
>>          http://www.heppnetz.de/ (personal)
>> skype:   mfhepp
>> twitter: mfhepp
>>
>> Check out GoodRelations for E-Commerce on the Web of Linked Data!
>> =================================================================
>> * Project Main Page: http://purl.org/goodrelations/
>>
>>
>>
>>
>>
>
Received on Saturday, 31 August 2013 03:18:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:29 UTC