W3C home > Mailing lists > Public > public-vocabs@w3.org > February 2012

Re: Comment versus UserComments

From: Dan Brickley <danbri@danbri.org>
Date: Thu, 1 Mar 2012 00:01:52 +0100
Message-ID: <CAFfrAFopB2hB0SnuaCyHBvDS82cfdVczgdgdbZMBm4KX_ekOJw@mail.gmail.com>
To: Stéphane Corlosquet <scorlosquet@gmail.com>
Cc: Daniel Dulitz <daniel@google.com>, public-vocabs@w3.org
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


Received on Wednesday, 29 February 2012 23:02:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:22 UTC