W3C home > Mailing lists > Public > public-vocabs@w3.org > November 2011

Re: draft JobPosting addition for Schema.org

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Wed, 9 Nov 2011 01:55:34 -0500
To: Jim Rhyne <jrhyne@thematix.com>
CC: "public-vocabs@w3.org Vocabularies" <public-vocabs@w3.org>
Message-ID: <09396A82-C505-4597-99D8-CCFD126E76FA@greggkellogg.net>
On Nov 8, 2011, at 9:20 PM, Jim Rhyne wrote:

> This is a perfectly good solution.
> An @itemscope without an @itemtype declares an untyped, anonymous
> individual.
> Can you point me to the part of the microdata specification that defines
> this interpretation? Is there a standard microdata to RDF translation?
> Thanks, Jim

If you look in the Microdata spec [1], you'll see examples of this usage. Microdata doesn't ascribe meaning to property names, but leaves that to vocabularies. There are examples of items with types having properties that are themselves items, but without types. In fact, in the (now removed) RDF transformation section, there's an elaborate scheme used to create URLs for these properties based on the referencing property and the associated itemtype.

The JSON transformation of this snippet would be the following (thanks to Phillip's Live Microdata service):
{
  "items": [{
      "type": ["http://schema.org/Person"],
      "properties": {
        "employee": [{
            "properties": {
              "jobTitle": ["Flunky"],
              "worksFor": ["Supervisor"]
            }
          }]
      }
    }]
}

The Microdata to RDF spec [2], which is a work in progress, describes a couple of ways to interpret itemprops without names, including those that are included in untyped items. For usage such as schema.org, GoodRelations and other vocabularies, the "vocabulary" URI generation scheme uses the closest in-scope itemtype to determine the vocabulary which is used for non-URI property names.

My own distiller implements something similar to this, you can check it out here [3]

Gregg

[1] http://www.w3.org/TR/microdata/
[2] https://dvcs.w3.org/hg/htmldata/raw-file/8cba9eceddc9/microdata-rdf/index.html
[3] http://rdf.greggkellogg.net/distiller?fmt=turtle&in_fmt=microdata

> Jim Rhyne
> Thematix Partners
> 
> -----Original Message-----
> From: Gregg Kellogg [mailto:gregg@kellogg-assoc.com] 
> Sent: Tuesday, November 08, 2011 2:28 PM
> To: Martin Hepp
> Cc: Jeni Tennison; public-vocabs@w3.org; Jim Rhyne
> Subject: Re: draft JobPosting addition for Schema.org
> 
> Hi Martin,
> 
> @itemtype is inherited to sub-items. So in this case, the vocabulary
> associated with the first @itemtype in the hierarchy is used. Using the
> vocabulary-centric RDF generation for schema.org:
> 
> <div itemscope itemtype="http://schema.org/Person">
>  <div itemprop="employee" itemscope>
>    <span itemprop="jobTitle">Flunky</span>
>    <span itemprop="worksFor">Supervisor</span>
>  </div>
> </div>
> 
> you should get the following output:
> 
> <> md:item [
>  a schema:Person;
>  schema:employee [
>    schema:jobTitle "Flunky;
>    schema:worksFor "Supervisor"
>  ]
> ] .
> 
> Gregg
> 
> On Nov 8, 2011, at 2:16 PM, Martin Hepp wrote:
> 
>> Hi Jeni:
>> But where are the properties jobTitle and worksFor then defined, if not at
> the itemtype type?
>> Martin
>> 
>> On Nov 8, 2011, at 10:56 PM, Jeni Tennison wrote:
>> 
>>> Hi,
>>> 
>>> It's not actually necessary to define "meaningless" classes for microdata
> vocabularies: you don't have to specify an itemtype on every item. In this
> case, you could do:
>>> 
>>> <? itemscope itemtype="http://schema.org/Person">
>>> ...
>>> <?? itemprop="employee" itemscope>  
>>> ...
>>> <??? itemprop="jobTitle">
>>> ...
>>> </???>
>>> ...
>>> <??? itemprop="worksFor">
>>> ...
>>> </???>
>>> ...
>>> </??>
>>> ...
>>> </?>
>>> 
>>> Of course it can also be useful to specify such a class so that you can
> describe things-which-can-have-jobTitle-and-worksFor-properties and restrict
> the employee property to have as a value that kind of thing.
>>> 
>>> Cheers,
>>> 
>>> Jeni
>>> 
>>> On 8 Nov 2011, at 21:14, Martin Hepp wrote:
>>> 
>>>> Hi Jim, all:
>>>> 
>>>> FYI: In the past, GoodRelations used a common superclass 
>>>> 
>>>>  http://purl.org/goodrelations/v1#N-Ary-Relations
>>>> 
>>>> that bundles all higher arity relationship types.
>>>> 
>>>> However, that has proven to be a practically useless and confusing
> class, so we deprecated that in GoodRelations a while ago.
>>>> 
>>>> I do not think there is anything wrong with defining types that are used
> for collating the various parts of a higher arity relation, neither in RDFa
> nor in Microdata.
>>>> 
>>>> Note that a generic type for this, e.g.
>>>> 
>>>>> http://schema.org/StructuredValues/3-aryRelation"
>>>> 
>>>> does not work in Microdata, because you would have to allow all
> properties of all usage contexts for this itemtype. Otherwise you would have
> to use full URIs for the itemprop attribute.
>>>> 
>>>> So AFAIK, there is no way to avoid defining types for important n-ary
> relations.
>>>> 
>>>> 
>>>> Martin
>>>> 
>>>> 
>>>> On Nov 8, 2011, at 5:10 PM, Jim Rhyne wrote:
>>>> 
>>>>> ----------------------
>>>>>> From: danbri2011@danbri.org [mailto:danbri2011@danbri.org] On Behalf
> Of Dan Brickley
>>>>>> Sent: Tuesday, November 08, 2011 12:44 AM
>>>>>> To: ptsefton@gmail.com
>>>>>> Cc: public-vocabs@w3.org
>>>>>> Subject: Re: draft JobPosting addition for Schema.org
>>>>> 
>>>>> ...
>>>>> 
>>>>>> When
>>>>>> someone has multiple roles, this doesn't capture the association, so
>>>>>> you might know someone is a 'Finance Manager'  but if they have
>>>>>> multiple 'worksFor', we don't know which job goes with which employer.
>>>>>> So there is clearly room to grow here
>>>>> 
>>>>> ...
>>>>> 
>>>>> This relation (Person, JobRole, Employer) is another example of the
> microdata representation problem I raised in my post of 27 October 2011
> regarding Distance. Because the current microdata specification allows only
> binary relations, one is forced to define a relatively meaningless class to
> link the three values together. The consequence is that the vocabulary
> becomes polluted with these relatively meaningless class names.
>>>>> 
>>>>> One way to deal with this is to adopt a convention to reuse @itemscope
> with a special set of @itemtype values, e.g.
> "http://schema.org/StructuredValues/3-aryRelation". In effect, this would
> define structured value classes for each arity relation with the @itemprop
> names serving as labels for the 2nd thru nth components of the relation. The
> @itemprop name of the property linking the enclosing item to the rest of the
> relation would serve as the label for the first component of the relation.
>>>>> 
>>>>> For example:
>>>>> 
>>>>> <? Itemscope itemtype="http://schema.org/Person">
>>>>> ...
>>>>> <?? Itemprop="employee" itemscope
> itemtype="http://schema.org/3-aryRelation">  
>>>>> ...
>>>>> <??? Itemprop="jobTitle">
>>>>> ...
>>>>> </???>
>>>>> ...
>>>>> <??? Itemprop="worksFor">
>>>>> ...
>>>>> </???>
>>>>> ...
>>>>> </??>
>>>>> ...
>>>>> </?>
>>>>> 
>>>>> Jim Rhyne
>>>>> Thematix Partners
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> -- 
>>> Jeni Tennison
>>> http://www.jenitennison.com
>>> 
>> 
>> 
> 
> 
> 
Received on Wednesday, 9 November 2011 06:56:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 06:48:57 GMT