Re: Comment versus UserComments

On Wed, Mar 7, 2012 at 1:59 PM, Daniel Dulitz <daniel@google.com> wrote:

> On Wed, Mar 7, 2012 at 12:18, Stéphane Corlosquet <scorlosquet@gmail.com>wrote:
>>
>> 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.
>>
>
> Me too.
>
> 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.
>>
>
> I could go for contentText; there are creativeworks where "body" doesn't
> really make sense.
>

Agreed, but how about just "content"?  Do we really need the data type in
the property name?


> 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.
>>
>>
> I'm a bit worried that we might have an attribute of CreativeWork that is
> supposed to describe the content, when all of the existing properties
> describe the content. So I'd tend towards type Text. But I don't feel too
> strongly, as long as whatever type is specified allows a simple text value.
>
>
>