Re: Comment versus UserComments

Currently CreativeWork has audio, video, and encodings properties. At least
the first two include the type in the name.

Let's assume we go with "content." Do we say it has type Thing and
deprecate audio and video? Just want to know how it goes...

On Wed, Mar 7, 2012 at 15:28, Jason Douglas <jasondouglas@google.com> wrote:

> 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.
>>
>>
>>
>