replace interactionCount with interaction

[elf-pavlik]

In one of last emails about differences between potential and active/compleated Action, I suggested introducing new property interaction which would supersede interactionCount - http://lists.w3.org/Archives/Public/public-vocabs/2014Sep/0174.html

{
  "@type": "WebPage",
  "@id": "http://example.net/",
  "interaction": [
    {
      "@type": "ViewAction",
      "@id": "http://mypds.net/joe/ew0r98a0ga",
      "actionStatus": "CompletedActionStatus",
      "object": "http://example.net/",
      "endTime": "2017-01-04T10:32:15+01:00"
    },
    {
      "@type": "ReadAction",
      "@id": "http://mypds.net/joe/0a9fd80gh7",
      "actionStatus": "CompletedActionStatus",
      "object": "http://example.net/",
      "startTime": "2017-01-04T10:32:15+01:00",
      "endTime": "2017-01-04T10:37:04+01:00"
    }
  ]
}

While on it, I would like to bring attention (for the 4th time in last 2
years) to: http://schema.org/interactionCount

And propose to replace it with interaction which would accompany
potentialAction on Thing.

• Thing --{potentialAction}--> Action --{actionStatus}-->
  PotentialActionStatus
• Thing --{interaction}--> Action --{actionStatus}--> ActiveActionStatus
  || CompletedActionStatus

[elf-pavlik]

search results for interactionCount in public-vocabs archives with comments from @zazi @Aaranged @BarryNorton

[gkellogg]

While I think having a schema:interaction property, it probably can't be comprehensive, and sites with large number of interactions may not want to represent all 10,000 likes, shares and so-forth. A summary is useful.

An alternative would be with something like Hydra collections, where the interaction property is put in a separate collection having its own summary information (totalItems). ItemList could do this, if it was externalizer and pagination.

[elf-pavlik]

@gkellogg good point! maybe then something in lines

{ "@id": "http://bigbuckbunny.org",
  "@type": "Movie",
  "interaction": [ {
    "@id": "http://bigbuckbunny.org/stats/liked",
    "@type": "hydra:Collection",
    "manages": {
      "property": "LikeAction"
    },
    "totalItems": 642
  }, {
    "@id": "http://bigbuckbunny.org/stats/watched",
    "@type": "hydra:Collection",
    "manages": {
      "property": "WatchAction"
    },
    "totalItems": 1250
  }, {
    "@id": "http://bigbuckbunny.org/stats/shared",
    "@type": "hydra:Collection",
    "manages": {
      "property": "ShareAction"
    },
    "totalItems": 148
  } ]
}

which would still allow both

Thing --{interaction}--> Action
                     --> hydra:Collection

@lanthaler

[gkellogg]

Except, of course that WatchAction, et.al. are not properties, but classes. Really, there would be a single collection managing schema:interaction, with different types values. In this case, it would make sense to have sub-properties of schema:interaction. In hydra, subset collections could also be returned using search "operations."

[elf-pavlik]

Of course I wrote nonsense using classes as properties 😒 Having an interaction sub property for each Action subtype doesn't sound that exciting. Taking step back from hydra:Collection, maybe introducing interactionStatistic which could take some kind of InteractionCounter would solve it?

{ "@id": "http://bigbuckbunny.org",
  "@type": "Movie",
  "interactionStatistic": [ {
    "@type": "InteractionCounter",
    "interactionType": "LikeAction",
    "interactionCount": 642
  }, {
    "@type": "InteractionCounter",
    "interactionType": "WatchAction",
    "interactionCount": 1250
  }, {
    "@type": "InteractionCounter",
    "interactionType": "ShareAction",
    "interactionCount": 148
  } ]
}

[zazi]

+1 for counter class, cf. http://purl.org/ontology/co/core#

[elf-pavlik]

@zazi would you change anything in my example? maybe introducing generic schema:count instead reusing existing but very specific schema:interactionCount ?

[zazi]

@elf-pavlik yes, this might be a good option. I would prefer schema:count instead of schema:interactionCount

[elf-pavlik]

relevant:

• http://schema.org/ratingCount
• http://schema.org/reviewCount
• http://schema.org/wordCount
• http://schema.org/upvoteCount
• http://schema.org/downvoteCount
• http://schema.org/viewCount
• http://schema.org/answerCount
• http://schema.org/commentCount
• http://schema.org/offerCount

[danbri]

Thanks for the detailed proposal. This clearly needs some attention now that Actions has shipped...

[danbri]

/cc @vholland

[vholland]

For issue #170, we were going to deprecate all of UserInteraction, which makes interactionCount useless.

It would be useful to have some sort of AggregateInteractionCount class so pages could mention how many times something has been liked or tweeted, which I think was the original intent of UserInteraction, but that is for another release.

[danbri]

I've generously assigned this to Vicki, since she is handling the UserInteraction area (and which looks likely to go away and take interactionCount with it).

Since the issue here is also forward looking, once interactionCount goes away, I'm moving it out from sdo-gozer into sometime-in-Q2.

[vholland]

In the spirit of @elf-pavlik's proposal, I put together vholland@a8c3e6c

The major difference is I did not leverage Action, for two reasons:

1. We would need to modify VoteAction or (create UpVoteAction and DownVoteAction) to make the up vote/down vote use cases work.
2. Other than the specific verbs chosen by various services, the semantic difference of "up voting", "liking", "plus'ing", etc are ambiguous. I would like to future-proof for the next big social media site that supports "hurrays".

To that end, I added the ability to say which site/app is used for the interaction so one can separate out Facebook likes from Youtube up votes.

[vholland]

Actually, the more I think about it, @elf-pavlik had the right idea. If I stop thinking in terms of up/down vote and in terms of http://schema.org/LikeAction and http://schema.org/DislikeAction, it works. It ties in Actions and doesn't require a bunch of new types.

I'll make that change tomorrow.

[vholland]

Please see pull request #514 for an implementation that uses Actions. I still need to update the examples, but pull requests are easier to diff against sdo-ganymede than individual commits.

[danbri]

@chaals - did you reach an opinion on this and the corresponding pull request, #514 ? /cc @tilid @ajax-als ... I believe everyone else is signed off. I will go ahead and merge it into the work-in-progress next release branch sdo-ganymede but do take a look...

[danbri]

see final review thread https://lists.w3.org/Archives/Public/public-schemaorg/2015Jul/0047.html