Re: Comment versus UserComments

Good points.  Pointing to Thing for a text value seems inconvenient, but
maybe shortening contentText to "text" (rather than "content") would be the
most clear and parallel, so: CreativeWork/audio, CreativeWork/video and
CreativeWork/text?

-jason


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

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