W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2014

Re: Person job proposal

From: Vicki Tardif Holland <vtardif@google.com>
Date: Thu, 18 Sep 2014 10:37:25 -0400
Message-ID: <CAOr1obGq7bvU-0+cGesZVLg33tgZ7FOm+dU_rX=6c5abZJwVRg@mail.gmail.com>
To: "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>
Cc: Guha Guha <guha@google.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>, Renato Iannella <ri@semanticidentity.com>
I hadn't actually considered the discussions around job/profession at all
heated. I believe that schema.org is strongest when it gets input from the
community at large. Some large classes have been added recently, and all of
them benefited from comments from the community.

Speaking for myself, I honestly mean it when I say comments are welcome.

- Vicki


Vicki Tardif Holland | Ontologist | vtardif@google.com


On Thu, Sep 18, 2014 at 3:33 AM, martin.hepp@ebusiness-unibw.org <
martin.hepp@ebusiness-unibw.org> wrote:

>
> On 18 Sep 2014, at 02:47, Renato Iannella <ri@semanticidentity.com> wrote:
>
> >
> > On 18 Sep 2014, at 02:33, Vicki Tardif Holland <vtardif@google.com>
> wrote:
> >
> >> I propose 5 properties and the mailing list goes nuts! ;-)
> >
> > That's what happens without a clear/transparent/open governance process
> ;-))
>
> +1
>
> I think the reasons for a lot of confusion and heated arguments are in the
> set-up of the schema.org community:
>
> 1. Schema.org is built on the assumption that you need to know, at least
> approximately, the data processing operations in order to build useful data
> structures. If I remember correctly, Guha states this in his Ontolog talk
> [1]. We are not building a generic conceptual model of the world, but
> instead one that, in the first place, can be used for preserving data
> structures and data semantics from the databases that drive dynamic Web
> applications, for information extraction by search engines. Read closely
> the schema.org mission statement [2].
>
> 2. In contrary to this assumption, the community typically knows very
> little or nothing about what the sponsors of search engines want to do with
> the data. This means that when making contributions and judging others'
> contributions, there is a lot of guessing. "When a man does not know what
> harbour he is making for, no wind is the right wind" (Senecca, see
> http://en.wikiquote.org/wiki/Seneca_the_Younger) ;-).
>
> For instance, we continously struggle to find the right level of ambiguity
> and granularity in the trade-off between simplicity for publishers
> (particularly in terms of how well a structure in schema.org matches the
> local schemas of existing data sources) and the effort to process the
> resulting data. We as a community hardly know to which degree
> Google/Bing/Yahoo/Yandex can handle unstructured and noisy data. We should
> not argue about philosophical distinctions that are either not relevant for
> computational operations or that can be easily reconstructed from plain
> text or other approaches.
>
> Schema.org will be most effective when it allows preserving such
> conceptual distinctions and data structures that are hard to reconstruct
> for search engines and easy to provide for site owners. Those are the sweet
> spots for schema.org.
>
> In the absence of such guidance from the major consumers of schema.org
> data, groups from various angles of the community throw in their
> interpretation of what one should be able to do with schema.org data -
> e.g. suitability for raw consumption in SPARQL in RDF worlds, etc.
>
> In traditional ontology engineering, defining the scope an purpose of the
> ontology is the first step. In the case of schema.org, we have an
> insufficient understanding of the scope and purpose. We are building one of
> potentially many Web vocabularies. Not the single one, but one that is
> often perceived as the borderline between practical relevance and ivory
> tower work, hence the high motivation of many to contribute.
>
> 3. Schema.org is currently designed as a monolithic, single-point-of-truth
> vocabulary. In particular, the use of
>
> a) global identifiers for properties and
> b) a single dominant hierarchy (with a few exceptions)
>
> means that the more populated schema.org gets, the more dependencies and
> potential conflicts emerge. If you add a single property here, it can
> create redundancies and inconsistencies with a lot of existing conceptual
> elements.
>
> In my opinion, these three points are the major causes that make our
> discussions more heated than necessary.
>
> Best wishes
>
> Martin
>
> [1] http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2011_12_01
> [2] http://schema.org/
>
> >
> >> As some have pointed out, Occupation and Job are slightly different. My
> occupation may be the same across employers, where as my job is not.
> >
> > According to [1], an Occupation is a "a person's job or profession"
> >
> > Schema.Org terms are not very well defined in this sense (aka ISO11179)
> and would benefit significantly if more concise definitions were applied
> consistently across concepts.
> >
> > Cheers...
> > Renato Iannella
> > Semantic Identity
> > http://semanticidentity.com
> > Mobile: +61 4 1313 2206
> >
> > [1]
> http://www.merriam-webster.com/dictionary/occupation?show=0&t=1411000183
>
>
Received on Thursday, 18 September 2014 14:37:53 UTC

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