Re: draft JobPosting addition for Schema.org

Hi Jim,
On 11/9/2011 6:20 AM, Jim Rhyne wrote:
> This is a perfectly good solution.
> An @itemscope without an @itemtype declares an untyped, anonymous
> individual.
I would say this happens when an @itemscope is not "value" on an 
INTENDED type. In the example below (slightly different from the 
previous one) a schema proccessor may consider "employees" content as  
an INTENDED Person instance.

<div itemscope itemtype="http://schema.org/Organization">
   <div itemprop="employees" itemscope>
     <span>John Doe</span>
     <span itemprop="|email|">johndoe@organization.com</span>
   </div>
</div>


> 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
Regards,
Adrian Giurca
> -----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
>>>
>>
>
>
>
>


-- 
- Adrian
/Follow Me on Twitter <http://www.twitter.com/giurca>
Connect on Linkedin <http://de.linkedin.com/in/adriangiurca> /