- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 8 Nov 2011 21:56:49 +0000
- To: Martin Hepp <martin.hepp@ebusiness-unibw.org>, public-vocabs@w3.org, Jim Rhyne <jrhyne@thematix.com>
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 Tuesday, 8 November 2011 21:57:28 UTC