- From: Stéphane Corlosquet <scorlosquet@gmail.com>
- Date: Wed, 7 Mar 2012 15:18:55 -0500
- To: Dan Brickley <danbri@danbri.org>
- Cc: Daniel Dulitz <daniel@google.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
- Message-ID: <CAGR+nnEwofQ9eQ=YkMazVAVofesvrwC1NSjEEWB9AD_jxeuMow@mail.gmail.com>
On Wed, Mar 7, 2012 at 2:47 PM, Dan Brickley <danbri@danbri.org> wrote: > On Thursday, 1 March 2012, Daniel Dulitz wrote: > > > > This looks good. +1 to the "bodyText" idea of a common property for all > similar types. > > > > At what level in the type hierarchy would "bodyText" go? > > > First reaction: CreativeWork. Second thought: WebPage? Or > WebPageElement ... Third reaction, ... back on CreativeWork. > I'm still on board with for Comment as subclass of CreativeWork. > > http://schema.org/Article has articleBody (Text) The actual body of the > article. > http://schema.org/Review has reviewBody (Text) The actual body of the > review. > > ...we could position this as a super-property of those, although that > is not necessary. All of these share Microdata's difficulty with > having markup-valued properties but of all these, bodyText of a > comment is the shortest and likely suffers least from that. > > Sometimes comments show up as a separate page, sometimes within a > page; so picking between WebPage and WebPageElement seemed difficult. > So my preference here is to add bodyText as a property of > CreativeWork. Second choice would be as a property of Comment, but > that seems overly restrictive. > having a generic property for the content of CreativeWork is appealing (e.g. bodyText). Does that property name have to make sense for all types of CreativeWork like Map, Movie, Painting, Photograph, Sculpture, TVEpisode? not sure. Maybe that's why Article and Review have their own dedicated property for their body. Maybe content or contentText is more generic than the notion of body? a question for native speakers. Steph. > > For its values, I'd prefer to leave open at 'Thing' for now (some > breathing room while we think about markup values); or 'Text' if we > must. We can always add more expected values later. >
Received on Wednesday, 7 March 2012 20:19:27 UTC