Re: as:Like (a rdfs:Class) or as:like (a rdf:Property) ?

On 08/25/2015 06:59 PM, Amy G wrote:
> Hey Pavlik,
> 
> I've spent some time trying to untangle this today, and I hope I've
> interpreted what you meant correctly...
> 
> Currently to like something with AS2:
> 
> * post a `Like` `Activity`, with `object` of liked-thing
> 
> I think you're suggesting to replace this with:
> 
> * post a `Create` `Activity` with `object` of `Relation` which has
> `property` of `likes` and `object` of liked-thing.
> 
> On the basis that you think the **Social API** should specify a side-effect
> of generating a `likes` direct relation between the liker and the
> liked-thing? And that in the case of this side effect, being able to map
> the qualified likes relation onto the direct likes relation using the same
> term is useful? And that this would also allow you to shortcut the creation
> of the `Activity` and just create the direct relation instead?
> 
> ActivityPump currently specs a similar side effect, of the `Like`
> `Activity` triggering the adding of the subject and object to various
> Collections which allows the improved querying I think is the main
> advantage of the direct relations.
I don't think we understand each other. I don't go here into API at all
and just focus on what we can and what we can NOT *express* with current
AS2.0 darft.

Can you provide JSON-LD which serializes information that you like 3
different resources, some Article, some Video and some FoodPlace ?

At the same time those resources need a way to also show that you and
other agents like them.

In other worlds an alternative to what I propose in JSON-LD which you
can find in
https://github.com/w3c-social/social-vocab/tree/master/verb/likes


> 
> I'm still not totally sure what the advantages to this additional level of
> abstraction for like relations is. As I see it, you've just replaced an
> `Activity` object with an additional `Relation` object, and shuffled some
> properties. Instinctively I don't think encouraging *only* direct relations
> is good, but I can see how they'd be useful in addition to qualified
> relations (which are *already* provided by an `Activity` with `actor` and
> `object`).
I do NOT replace Activity object with Relation object. Let's say I
visted Berlin 20 times so far. I would have a direct relation, qualifed
relation and 20 activities:

    {
      "@id": "https://wwelves.org/perpeual-tripper",
      "@type": "Person",
      "displayName": "elf Pavlik",
      "visits": [
        "http://dbpedia.org/page/Berlin"
      ],
      "relation": [
        "https://graph.wwelves.org/e1e677ab-8427-40a6-a177-ef7b48254633"
      ]
    },
    {
      "@id":
"https://graph.wwelves.org/e1e677ab-8427-40a6-a177-ef7b48254633",
      "@type": "Relation",
      "subject": "https://wwelves.org/perpeual-tripper",
      "object": "http://dbpedia.org/page/Berlin",
      "property": "visits",
      "activity": []
    }

where activity array will have 20 elements with: "@type": "Activity"

> 
> The way it's done using microformats is different again, but more similar
> to a `Like Activity`, except the `object` property is replaced with a
> `like-of` property, and there is no explicit `type`. But this is still the
> same qualified relation, in the same way AS2 does it. The semantics of the
> `like-of` property are *not* the same as a `likes` property that would
> exist between the liker and the liked-thing, so this doesn't match what
> you're suggesting.

Yes, *I* like a video and *I* visit a city, not my post likes something
or my posts visits something. Could imagine writing JSON-LD version
which uses mf: vocabulary of how someone describes a like or a visit in
microformats? I could later draw graph diagrams for it to visualize it
and compare further.

> 
> I don't think this needs to get any more complicated for
> follow/subscribe/friend relations. ActivityStreams already has a
> `Relationship` object for relationships between Actors, and doing a friend
> request and acceptance using existing AS2 terms is walked through in
> [3.1.1.1](
> http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams-vocabulary/index.html#connections
> ).

I suggested changing a & b to subject & object for as:Relationship

http://www.w3.org/TR/2015/WD-activitystreams-vocabulary-20150722/#dfn-relationship

I would consider

as:Relationship rdfs:subClassOf :Relation .
and
as:relationship rdfs:subPropertyOf :property

Which restrict subject and object to as:Actor and recommend
http://purl.org/vocab/relationship/ for values of as:relationship

Still with :Relation and :property I propose we have the same but more
generic pattern for non Actor <-> Actor (Agent <-> Agent) relations.


Currently defining as:Like, as:View, as:Read etc. gives no other benefit
than filtering Activities by activity["@type"].includes('Like')

With as:like, as:view, as:read etc. we could do the same to filter
activity.verb.include('like') or activity.action.includes('like')

But could *also use them* for labels in edges of direct relations, for
values of property in qualified relations, and for values of verb/action
in activities!

I hope that clarifies my argument :)

> 
> On 14 August 2015 at 21:44, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
> wrote:
> 
>> Hello,
>>
>> I should have chance in next days to discuss this issue with people
>> working on xAPI, please also notice creation of
>> EXPERIENCE API (XAPI) VOCABULARY & SEMANTIC INTEROPERABILITY COMMUNITY
>> GROUP
>> * https://www.w3.org/community/xapivocabulary/
>>
>> Today, during xAPI Vocabulary call, Tom De Nies explained his work on
>> http://tincan2prov.org
>>
>> In accompanying presentation, you can find diagram where *completed*
>> verb appears as label of an edge. Which looks to me like rdf:Property
>> see Slide 9
>> *
>>
>> http://www.slideshare.net/tdenies/20150519-tom-de-nies-tin-can2prov-exposing-interoperable-provenance-of-learning-processes-through-experience-api-logs
>>
>> I still need to catch up with AS2.0 going CR thread but I think we
>> should consider this possible non trivial change before deciding to go
>> into CR...
>>
>> Cheers!
>>
>>
>> On 07/20/2015 02:53 PM, ☮ elf Pavlik ☮ wrote:
>>> Hello,
>>>
>>> (cc: IG Vocabulary TF)
>>>
>>> I would like to bring this topic to our attention right away, since it
>>> may require non trivial change to current AS2 drafts.
>>>
>>> Currently we use sub classes of as:Activity for 'verbs', I see various
>>> benefits of using properties instead. Some prior conversations where I
>>> argued quite opposite:
>>> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/23
>>>
>>> My reflection come in big part from drawing diagrams representing graphs
>>> with social data, for example:
>>>
>>> * https://github.com/w3c-social/social-vocab/tree/master/activity/Follow
>>> *
>> https://github.com/w3c-social/social-vocab/tree/master/activity/Subscribe
>>>
>>> As we see, to use direct relations (not qualified relations) we still
>>> need predicates like: *follows*, *subscribes*, *likes*, *attends* etc.
>>>
>>> BTW I don't even pay attention now to what seems like a minor detail
>>> follow/follows/followed like/likes/liked etc.
>>>
>>> It could possibly work much simpler to define verbs as
>>> properties/predicates and just use them directly
>>>
>>> {
>>>   "@context": [
>>>     "http://www.w3.org/ns/activitystreams",
>>>     "v": "http://w3id.org/verb/#"
>>>    ],
>>>   "@id": "https://wwelves.org/perpetual-tripper",
>>>   "v:follow": [
>>>     "https://aaronparecki.com/",
>>>   ],
>>>   "v:subscribes": [
>>>     "https://aaronparecki.com/metrics",
>>>   ],
>>>   "v:attend": [
>>>     "https://www.w3.org/wiki/Socialwg/2015-07-21",
>>>   ]
>>> }
>>>
>>> As for today, I don't see example of how to show 'who likes this
>>> posting' - (similar to
>>>
>> https://developers.facebook.com/docs/graph-api/reference/v2.3/object/likes
>> )
>>>
>>> I will prepare another example with an event, which will require linking
>>> to collections of agents (actors) via edges: invite, subscribe, attend,
>>> host, sponsor etc.
>>> (similar to
>>>
>> https://developers.facebook.com/docs/graph-api/reference/v2.3/event#edges)
>>>
>>> Since we don't use (at least as normative) rdfs:domain and rdfs:range,
>>> defining more specific sub classes of as:Activity doesn't seem to offer
>>> any benefit.
>>>
>>> Some examples where actions/activities seems get used in a way that
>>> would fit defining them as properties not classes:
>>>
>>> * http://adlnet.gov/expapi/verbs
>>> * http://indiewebcamp.com/webactions#action_do_verbs
>>> * http://microformats.org/wiki/h-listing#Properties (p-action)
>>> * http://microformats.org/wiki/h-entry#Draft_Properties
>>> * https://developer.github.com/v3/activity/events/types/
>>>
>>> I don't see any agenda for tomorrow yet, maybe we could all think about
>>> it and have short initial discussion about pros and cons of those two
>>> different approaches tomorrow?
>>>
>>> Cheers!
>>>
>>
>>
>>
>