Re: feedback on some Action subtypes

Hi Sam & Thor :) At this moment I still explore Action subtree and try 
to wrap my head around it... I plan to start using it next days&weeks in 
few small open source projects, so will have possibility to offer some 
feedback based on precise use cases and with references to all the 
relevant source code (javascript). Actions schema looks very promising, 
thank you for putting effort into specifying them!

On 11/25/2013 11:28 PM, Sam Goto wrote:
> +thor, who was very active in writing these individual actions with me
>
> Hi Elf! Thank you for the feedback, certainly much appreciated!
> Responses inline!
>
>
> On Mon, Nov 25, 2013 at 9:08 AM, ☮ elf Pavlik ☮
> <perpetual-tripper@wwelves.org <mailto:perpetual-tripper@wwelves.org>>
> wrote:
>
>     Please let me know if i can find better channel then this list to
>     share such feedback!
>
>     * http://schema.org/JoinAction
>     ** Parent type Action already has property *object* used in
>     JoinAction examples with SportsTeam, MusicGroup and TheatreGroup. I
>     don't understand why we make *Event* a special case and use *event*
>     property instead of generic *object*.
>
>
> Yep, known bug, will be removed in the latest builds.
>
>
>     * http://schema.org/__CheckInAction <http://schema.org/CheckInAction>
>     ** If I check in to a Place or Event they already might have
>     *location*. I would find very useful suggestions, from people who
>     implemented such cases, if they simply copy object.location into
>     location?
>
>
> That's a reasonable point and certainly one that I've heard before. I
> think you are generally right, but the details/context are important too.
>
> My intuition is that reasoners (e.g. google, bing, gmail, etc) need to
> understand both forms. Not *all* types of check-ins have a "location"
> property, and I want to optimize for how easy this schema is for the
> developer to produce.
>
>     ** Example "John checked in at Yandex" links to Place using
>     *location* property. I have impression that some implementations
>     might use generic *object* property instead. How about convention:
>     "Use location for actions only if different then object"?
>     ** Example uses not existing object - type *Flight*
>     ** Looking at properties from CommunicateAction I have impression
>     that CheckInAction doesn't fit as its sub type.
>
>     * http://schema.org/__PhotographAction
>     <http://schema.org/PhotographAction>
>     ** Example "John took a photo of Steve." puts ImageObject as
>     *object* property where *result* property seems to fit more to link
>     Image, while Steve would fit as *object*?
>
>
> Good point. Bug. I'll file a bug report for me to fix this.
>
>
>     * http://schema.org/__CommentAction <http://schema.org/CommentAction>
>     ** Example "John commented on a blog post.", object=UserComment &
>     about="ScholarlyArticle". My first thought led in direction
>     object=ScholaryArticle & result="UserComment"... (result explained
>     with: e.g. John wrote *a book*.) I don't argue that we should model
>     it the second way, but maybe provide links to strong reasoning why
>     preference of one way over another! (similar to previous example of
>     PhotographAction)
>
>     * http://schema.org/__SubscribeAction
>     <http://schema.org/SubscribeAction>
>     ** missing UnSubscribeAction ? (eg.
>     http://lists.w3.org/Archives/__Public/public-vocabs/2013Nov/__0176.html
>     <http://lists.w3.org/Archives/Public/public-vocabs/2013Nov/0176.html>)
>
>
> Yep, we'll be adding all these antagonyms as needed. Do you actually
> need these antagonyms or are you just pointing out that
>
>     * http://schema.org/FollowAction
>     ** missing UnFollowAction ? (i do it very often during online
>     activities! twitter etc.)
>
>     * http://schema.org/__BefriendAction <http://schema.org/BefriendAction>
>     ** missing UnFriendAction ? (sad but happens ;)
>
>     * http://schema.org/MarryAction
>     ** missing DivorceAction ? :D
>
>     I plan to look on other actions in near future. Once again, if you
>     can think of better way for me to provide feedback, please let me know!
>
>
> Thanks! Much appreciated! This is early enough that changing these
> actions isn't terribly hard, so now is the perfect time for more feedback!
>
> Sam
>

Received on Tuesday, 26 November 2013 10:43:01 UTC