Re: a user liking a post

On 23 August 2015 at 10:56, Amy G <amy@rhiaro.co.uk> wrote:

>
>> 1. _:like-of here implies it's a bnode, but I think it's not actually a
>> bnode.  It's going to be problematic for many to reuse this predicate
>> without the predicate being a URL.  Is this something on the horizon, do
>> you know?
>>
>
> I couldn't say. I actually store <http://vocab.amy.so/blog#like_of> at
> the moment, which was only ever intended to be temporary (eg. curl -H
> "Accept: text/turtle" http://blog.rhiaro.co.uk/1438621461)
>

Very nice!  But as you say, this is temporary.  It would be nice to know if
something more permanent could be achieved in the lifetime of this WG.  I
think that would incentivize reuse.


>
>
>>
>> 2. The semantics of a post liking another post seems slightly unnatural
>> to me.
>>
>
> The semantics are *not* 'a post likes a post'. The semantics are 'this
> post represents a like of this other post'. Hence *like-of*, not *likes*.
> A post in this sense could be considered exactly the same as an AS2 Like
> Activity. They are both objects which represent a relationship between a
> person (the author/creator/actor) and another object (the post). Whether
> this relationship should be made more explicit is subject for a different
> thread I guess (possibly something the API can resolve, as AP starts to
> specify - see 1.1 <http://w3c-social.github.io/activitypump/#Overview>).
>

Got it.  I guess this would be phase 2 for me.  So I'll come back and
revisit after I have the first part working, but it's helpful to see both
parts.


>
>
>>   I guess this is more for the notification in a stream once a like has
>> been performed.
>>
>
> Ah, I think you mean the notification in stream *as opposed to a list of
> things a user likes*. Well, either could trigger either, I guess.
> Starting from the users' perspectives:
>
> > I see your post I like, click 'like'.
> > you see notification "Amy liked your post"
> > I see in my feed "you liked Melvin's post"
> > Jessica sees in her feed "Amy liked Melvin's post"
> > On my profile, the list of things I like grows to include your post.
> > On your post, the number of 'likes' displayed is incremented.
>
> All of these results can be triggered either by creation of a Like type
> object / like-of post, or creation of a direct *likes *relation between
> me and the post. Personally I prefer the first option (which can generate
> the direct relation if need be), for reasons I've already said (metadata,
> linkability).
>

Great, that's a useful user experience.  Currently the way I do
notifications is through a websocket in realtime.  But a more persistent
store of events is useful.  We talked about a "primaryInbox" lately where I
could persist such objects for a user.  In Linked Data a user is not
restricted to a single inbox, so one suggestion was to have a "primary"
place to persist such objects.


>
>
>> In my scenario the like object can live anywhere.  That's an
>> implementation detail.
>>
>
> I'm not sure what the 'like object' is in your scenario, as you have only
> indicated the direct relation between the person and the liked thing so
> far. Did I miss something? My response has been on the basis that you do
> not have a 'like object', just a relation.
>

There's two styles of relation in linked data, one is   X  likes  Y.  ie
with a single predicate.  The other is a more complex object.  L a like ;
liker X ; likee Y ; url U .  for example.  The 2nd part is considerably
more complex than the first, e.g. for querying, for coding, to create a
persistent identifier, for updates etc.  For example I can have a heart
button on my UI to add and remove a like, and leave notifications
orthogonal.  This is easy to remove and add.  There's time when you want to
use a simple relation, and times when you want to use a more complex
container.  My first use case is the simple relation, which I think is
going to be needed but lots of software.

The general rule is that if there are only 2 actors in the object, you can
use a simple relation.  "X likes Y".  If there are more you a complex
object e.g. "X pays Y 10 dollars"


>
>
>>   In practice I think I will go with putting the like as close to the
>> liked thing as possible, as it may turn out to be easier to discover.
>>
>
> I'd be inclined to prioritise data ownership for users, and put the like
> as close to the author as possible, rather than the liked thing.
>

Perfectly reasonable also.  Each approach has pros and cons.


>
> Amy
>
>
>
>
>>
>>
>>>
>>> Interestingly, I don't think any of the major centralised social
>>> networks I've looked at have external URIs for likes, but I think it's a
>>> safe bet they have internal ones and store data about the *like *happening.
>>> Twitter doesn't even allow you to get a list of users who have favorited a
>>> tweet through their API (though on an individual tweet there's a boolean
>>> "favorited" property) and a quick search will reveal lots of developers
>>> complaining about this inability..
>>>
>>
>> Well that gives us a competitive advantage then, namely, unexpected reuse.
>>
>>
>>>
>>> Amy
>>>
>>> On 23 August 2015 at 01:23, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>> I've noticed that the concept of a user liking a post is deployed in a
>>>> number of systems.
>>>>
>>>> But it seems there are a number of ways of doing it.
>>>>
>>>> I just wanted to see if there are pros and cons of different approaches.
>>>>
>>>> Right now I do something like:
>>>>
>>>>   <#me> <http://ontologi.es/like#likes> <content>
>>>>
>>>> It seems simple, lightweight and meets my needs.
>>>>
>>>> Are people in general going to use AS2 for this, is there a good vocab
>>>> to switch to?
>>>>
>>>> Thoughts appreciated ...
>>>>
>>>
>>>
>>
>