Re: Comment versus UserComments

This all sounds great, I like the idea of a text property. 

Quick question though - will the articleBody & reviewBody attributes be removed/deprecated?

As this would require changes to The NYT implementation and the IPTC rNews documentation, I suggest that we not remove/deprecate these properties.

All the best,

Evan Sandhaus
Lead Architect, Semantic Platforms
The New York Times Company

On Mar 8, 2012, at 3:38 PM, Dan Brickley wrote:

> On 8 March 2012 17:32, Michael Hausenblas <> wrote:
>> +1
> Thanks!
> Ok, I've updated the Wiki summary, including what is hopefully a
> near-final summary of the proposal:
> Here's the raw wiki text directly:
> == Core Proposal ==
> Proposal finalised in thread leading to
> [
> march 8th agreement]:
> * Add a 'Comment' type, a subclass (e.g. like
> [ Review]) of [
> CreativeWork].
> ** A comment on an item - for example, a comment on a blog post.
> * Clarify that the existing [
> UserComments] class represents the [
> UserInteraction] event that creates it.
> * Add a 'text' property to the [
> CreativeWork] class, whose value is the [ Text]
> of the work (and hence of the comment); loosely analogous to the
> 'audio' and 'video' properties of CreativeWork.
> * Note that this (to some extent) this generalises the articleBody
> property from [ Article] and the  reviewBody
> property from [ Review], rather than adding
> another class-specific property for Comment.
> * Note that the 'text' property's value is plain text rather than
> markup, due to Microdata's datamodel restrictions; defer any attempt
> at markup-valued properties for later work.
> There were a few fiddly details noted in the issues section. I've
> drafted resolutions here:
> """
> Do we have a property linking a UserComments instance (ie. some
> UserInteraction) to its resulting Comment?
> -not directly proposed at this time
> -note that each UserComments interaction event can have a 'discusses'
> link to the CreativeWork being commented upon.
> -note that the resulting Comment (itself also a CreativeWork) will
> typically be 'about' that same CreativeWork
> -it seems plausible to expect the dateCreated of the Comment to
> usually match the commentTime of the UserComments event; however,
> perhaps spam filtering processes might mean this differ?
> Do we have any comment-specific properties, or CreativeWork gives us
> all we need.
> -"author," "headline," are inherited from CreativeWork (amongst other
> useful properties); also "about": for a Comment, if it points to an
> item, the comment is about that item.
> Address here also other confusions around the UserComments class, such
> as that its siblings are aggregates and the example goofy?
> -can be dealt with separately.
> Recursion; how useful is 'discusses' for linking comments in a thread,
> since a Comment is a legitimate CreativeWork now?
> -discusses retains its original purpose (links event of a comment to
> the thing commented on); 'about' links a Comment CreativeWork to the
> other Work it comments upon."""
> How does this look, folks?
> Is anyone suffering for lack of a relationship from the UserComments
> instance to the associated Comment? I'd suggest it could be added
> later if a case is made.
> Dan

Received on Thursday, 8 March 2012 20:46:57 UTC