RE: draft JobPosting addition for Schema.org

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

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 05:21:25 UTC