Re: Comment versus UserComments

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?

On Wed, Feb 29, 2012 at 15:01, Dan Brickley <danbri@danbri.org> wrote:

> On 29 February 2012 23:33, Stéphane Corlosquet <scorlosquet@gmail.com>
> wrote:
> > On Wed, Feb 29, 2012 at 5:09 PM, Dan Brickley <danbri@danbri.org> wrote:
> >> On 22 February 2012 21:27, Daniel Dulitz <daniel@google.com> wrote:
> >> > I just wanted to follow up on this. I like the ideas mentioned here...
> >> > seeing no further debate can we close on a new Comment type? :-)
> >>
> >> I've added a row to the proposals table for this, and a Wiki page -
> >> http://www.w3.org/wiki/Comment  in
> >> http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals
> >>
> >> The core proposal of adding a new type seems to have consensus, and we
> >> should do it. I was just adding some more details but I'm finding the
> >> wiki suddenly horribly slow the last half hour. It seems fine right
> >> now; (maybe some spam-bot attack?).
> >>
> >> I'll paste the wiki text below here in case others have the same
> >> experience. If we can wrap up how deep we want to go in this round
> >> (eg. supporting properties), it would be great to turn this into an
> >> update proposal for the site. Adding 'Comment' seems clear progress;
> >> but then how much more do we do in one step? commentBody property?
> >> Plain text, or (if Microdata allows) markup somehow?
> >
> >
> > I think there should be some consistency with the CreativeWork types like
> > Article. Btw, any reason why Comment cannot be a subtype of CreativeWork?
>
> No reason at all. That's the main proposal:
>
> * Add a 'Comment' type, a subclass (e.g. like Review) of CreativeWork.
>
> > though some properties from CreativeWork are overkill for Comment, it
> would
> > save us from having to recreate properties for Comment.
>
> Absolutely. Also note that other extensions are also enriching
> CreativeWork. I'm not sure the LMRI properties explicitly only work
> with that class, but it seems to be their main target. So educators
> and 'virtual learning' software systems for example might consider
> combining "Comment" with properties from LRMI that address
> education-related scenarios.
>
> > There should be at least a property for the body... aside: commentBody,
> articleBody, is it good practice to include the type in a property?
>
> Maybe this identifies a need for a generic 'bodyText' (or similar)
> property.
>
> > re markup, microdata does not allow markup so there isn't much we can do.
> > articleBody does not mention anything about markup so I don't think
> > commentBody should either.
>
> There's always a way, if you don't mind ugly. In RSS feeds for example
> there used to be a lot of entity-escaping. Not that I'd recommend
> this!
>
> cheers,
>
> Dan
>