This was motivated by its inclusion in AS1 and backwards compatibility, but even there its' duplicative of the Object author property, especially as Activities are a subclass of Objects.

Proposing that we remove actor. People translating AS1 to AS2 should replace all uses of "actor" with "author". People translating AS2 to AS1 for legacy systems should perform the inverse conversion on all activities.

The "Link Value" type as defined in the present AS2 draft suffers some issues:

1. The term "Link Value" is overly generic
2. It permits multiple objects in contexts where only one should be provided (e.g. the object property of an activity)

My suggestion is:

1. We define the concept of "Abbreviation", in which it is permitted for certain types to be substituted for an abbreviated form.
2. For Objects, we define that a string which contains an IRI as the permitted abbreviation, in which case the string contains the ID of an object, and which corresponds to the unnabbreviated object { "id": /that-string/}
3. For Lists of Objects, we define the abbreviated form to be an Object (which may itself be abbreviated), which corresponds to an array in which a single entry is that object
4. We then replace references to Link Values with Object/List of Objects as appropriate

While I feel that this stands on its' own, it also ties in with the Media Source concept, which I will submit shortly.

I will track here setup for automated testing

• validate activitystreams2.owl
• validate *-context.jsonld
• test examples if JSON-LD, Turtle and RDFa serialize same graph (isomorphism)

The spec currently points to the RFC5988 definition of a link relation. @tantek points out that HTML5 has its own definition that he argues is a better normative reference.

The definitions differ slightly. The 5988 definition has a strict definition.

Recommend a compromise:

1. AS2 spec would point to RFC5988 as the normative definition but would also say that all link rels must also be valid in HTML5
2. The spec would clarify that link relations are not required to be registered in the 5988 defined IANA registry.

Currently, the draft leaves it somewhat unclear how an agent is supposed to locate and choose the media resource associated with objects (e.g. an image accompanying a "note", or the video behind an actual video object)

I do not attempt to fully clarify that issue here. Instead, I propose a mechanism by which we may do so: The "Media Source" object. This is based upon evolving and clarifying the "Media Link" object from AS1.

Media Source objects

Media Sources are JSON Objects which define an "embedded rich content" resource; they serve a purpose analogous to the element in HTML. They have the following attributes, which bear the same name and definition as the corresponding attribute in HTML5 where applicable:

• src: contains the URI of the media file in question. All Media Sources must contain a src attribute.
• type: If present, must contain a valid MIME type, which is the same as the MIME type of the resource pointed to by src. All Media Sources should provide a type attribute.
• width and height: If present, these properties declare the width and height, in pixels, of the linked media. Sources with a visual component should provide width and height attributes; sources without a visual component must not provide width and height attributes.

(Open question: do we also provide the media attribute from HTML?)

A Media Source object may be abbreviated to a string which contains the value of the src property.

Media Source lists

A Media Source list is a JSON array of zero or more Media Source objects, all of which correspond to different encodings of the same resource. The list should be sorted from most preferred version to least preferred (where the most preferred version need not correspond to the highest quality version); clients may implement their own preference system.

A Media Source list may be abbreviated to a single Media Source object, which may itself be abbreviated. This corresponds to a single element array.

JSON-LD can be serialized in a number of ways. Too many options make life difficult. Let's keep it as simple as possible... Proposal: A valid AS 2.0 document would be required to be in JSON-LD compacted form.

reported by @pfps via: http://lists.w3.org/Archives/Public/public-vocabs/2014Nov/0025.html

I also noticed that NaturalLanguageValue has the wrong superclass - it should be languaged typed string.

Many social systems use a in-band mechanism to let users define special addressing for messages. For example, "@username" often will route a note or image to a special "mentions" or "inbox" stream for a user.

It would be worthwhile to note that Activity Streams 2.0 processors should not have to parse the "content" or other properties of activity objects to determine this addressing information. Instead, the stream creator SHOULD put explicit addressing information into the activity using "to" or "cc", and MAY replace "@username" in the content with a link to an appropriate page for that user.

Background

as:Group
http://www.w3.org/TR/activitystreams-vocabulary/#dfn-group
"Represents a formal or informal collective of Actors."

as: Collection
http://www.w3.org/TR/activitystreams-vocabulary/#dfn-collection
"A Collection is a subclass of Object that represents ordered or unordered sets of Object or Link instances..."

as:items
http://www.w3.org/TR/activitystreams-vocabulary/#dfn-items
"Identifies the items contained in a collection. The items might be ordered or unordered."

as:memberOf
http://www.w3.org/TR/activitystreams-vocabulary/#dfn-memberof
"Identifies a collection this object can be considered a member of"

Questions

1. How do we model members of the group? I proposed exercise with modeling SocialWG members in https://www.w3.org/wiki/Socialwg/Collection_Comparison
2. How do we model collection of events associated with this group?
   e.g https://www.w3.org/wiki/Socialwg#Past_Telecons_.26_Meetings

See also

• http://schema.org/event
• http://www.w3.org/TR/ldp/#ldpdc
• https://www.w3.org/community/hydra/wiki/Collection_Design

See: http://lists.w3.org/Archives/Public/public-socialweb/2014Nov/0011.html

The "rel" property added to the as:Link is problematic from a data
modeling point of view, and actually isn't as useful as one might
imagine in practice.

Based on the current definition of as:Link, here's how it would
currently be used:

{
"@context": "http://asjsonld.mybluemix.net",
"image": {
"@type": "as:Link",
"@id": "http://example.org/foo",
"rel": "preview"
}
}

Those familiar with the JSON-LD processing model ought to see the
problem right away. The "rel" is actually supposed to be a qualified
relation of the containing object, but as it is defined here, it
becomes a property of the as:Link itself.

In any case, despite the modeling issues, the "rel" just isn't proving
to be very valuable in any case I can identify.

My proposal is just to remove it.

Representing people as URNs is obscure and unhelpful. People have URLs and are widely represented by them on the web.

Right now, the core AS 2 spec includes a broad list of generally optional attributes. Implementers currently support a mixed bag of these, with no two supporting exactly the same set. By leveraging our extensibility model (and the JSON-LD alignment) we can split the optional bits off to a separate adjunct document and JSON-LD @context. They'd still be defined for impls that need them, but the core AS 2 doc would get quite a bit shorter.

The <link> tag is purely for document-level references. See http://www.w3.org/TR/html5/document-metadata.html#the-link-element

A link element must have a rel attribute.
If the rel attribute is used, the element is restricted to the head element.

Hyperlinks created with the link element and its rel attribute apply to the whole page. This contrasts with the rel attribute of a and area elements, which indicates the type of a link whose context is given by the link's location within the document.

If we look here: https://www.w3.org/wiki/Socialwg/Social_API/User_stories

There are a number of Object and Activity Types currently not covered by the Activity Streams vocabulary. There are also some that may need to be tweaked.

• Profile - We have "Page" and "Person" object types, but not a "Profile" object type. Should we add one? Example use "John updated his Profile"
• Avatar - We have an "Image" object type, but not one that is specifically "Avatar". Right now, we can associate an "image" with a "Person" which serves the same purpose, but do we need "Avatar" as a first class object type? Example use "Sally created her Avatar"
• Hide, Revoke and Redact - These are a bit odd but go along with the privacy user stories.

Example 51 in a spec currently suggests

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    { "@language": "en" }
  ],
  "displayName": {
    "@value": "This is the title",
    "@language": null
  }
}

but it doesn't work in JSON-LD playground http://json-ld.org/playground/#/gist/0d3cecac2b124f67b85f

looks like "@language": null causes some problem when parsed

when removed just use of "@value": This is the title" removes the default language
http://json-ld.org/playground/#/gist/79291ee35c028fddf5bd

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    { "@language": "en" }
  ],
  "displayName": {
    "@value": "This is the title"
  }
}

_:b0 <http://www.w3.org/ns/activitystreams#displayName> "This is the title" .

We could try to create separate context to add when processing AS1.0 documents. It would provide graceful degradation requiring some additional post processing (seeAlso #14)

• #23 redefine as:verb
• Activity Streams 1.0 Terms

The new W3C Namespace URI needs to point to the JSON-LD @context document with proper CORS headers and content type declaration

Discussion started in issues#23

TL;DR during processing RDF we can't depend on identifiable blank nodes identifiers, also related to persisting in triple stores "seeAlso": "levelgraph/levelgraph-jsonld#8 (comment)"

Expanded

  "http://activitystrea.ms/2.0/verb": [
    {
      "@id": "_:post"
    }
  ]

Compacted

  "http://activitystrea.ms/2.0/verb": {
    "@id": "_:post"
  }

Flattened

  "http://activitystrea.ms/2.0/verb": {
    "@id": "_:b1"
  }

Framed

  "http://activitystrea.ms/2.0/verb": {
    "@id": "_:b1"
  }

N-Quads

  _:b0 <http://activitystrea.ms/2.0/verb> _:b1 .

Normalized

  _:c14n1 <http://activitystrea.ms/2.0/verb> _:c14n0 .

"as:cc": ["@jasnell", "@lanthaler", "@gkellogg"]

@elfpavlik will report after #17 -> automated testing runs <- #32

"seeAlso": " https://github.com/bergos/rdf-ext/issues/3"

In the original AS 2.0 draft, the default language context was set using the "language" property... e.g.

{
  "language": "en", 
  "displayName": "foo"
}

The only way to do this using a pure JSON-LD approach is to use:

{
  "@context": {"@language": "en"}, 
  "displayName": "foo"
}

See: http://lists.w3.org/Archives/Public/public-socialweb/2014Nov/0010.html

"The "Natural Language Value" construct in AS2 was originally added
before the serialization of AS2 was formally based on JSON-LD. The
mechanism is intended to provide a default language context for the
document, but it's not entirely compatible with the JSON-LD mechanisms
and requires a pre-processing step to be implemented before successful
JSON-LD processing... At this point, I think it makes sense to simply remove the Natural
Language Value construct and rely specifically on the JSON-LD
mechanisms to eliminate the additional pre-processing step. Doing so
makes things a bit more reliant on JSON-LD but simplifies things
overall."

It points to http://www.w3.org/TR/WD-activitystreams-vocabulary-20150129/.

Section 2.2, 3 and 3.1 contain an occurrences of the link.

in the media type registration http://www.w3.org/TR/activitystreams-core/#media-type, would it make sense to explicitly point out that the media type covers two "types" of documents, one being activity objects and one being collections? that would be the starting point for any implementer, right? request and/or get the media type, and then know what to expect.

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html#terms
has this Definition for self:

A LinkValue referencing the link context.

but it is not defined what a "link context" is.

http://www.w3.org/2014/Process-20140801/#working-draft states:

A Public Working Draft is published on the W3C's Technical Reports page [TR] for review, and for simple historical reference. For all Public Working Drafts a Working Group

• SHOULD document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
• MAY request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.

I propose adding more significant issues inline to the spec, currently:

• #27 Reference context in examples

ISSUE: currently all the examples don't include JSON-LD @context you can find working version at http://asjsonld.mybluemix.net/

• #24 as:Link from Linked Data perspective + comparing with hydra:Link

ISSUE: as:Link uses same @id as resource it targets and most of its properties (except as:rel) describe the representation of a resource it targets not the link itself

• #23 as:Verb & as:verb possibly not needed

ISSUE: as:Activity and as:PotentialAction use @type and/or as:verb to specify their type

• #36 as:verb - consequences of using blank node identifier (eg. _:post)

ISSUE: using blank node identifiers (eg. _:post) for values of as:verb can cause problems with comparing it across multiple JSON-LD documents even when they serialize single activity stream. Persisting activities with such blank node identifiers in triple stores will also result in them changing to different, not predictable, blank node identifiers. Also various processing algorithms will relabel blank nodes.

On the mailing list, Owen Shepherd raised a question about the definition and use of "url" in AS2. In AS1, "url" was defined strictly as a string IRI. In AS2, it's defined as a Link Value. It's use, however, is rather overloaded and the semantics are poorly defined.

Alternatively, we can use RFC 5988 Link Relations to provide semantically meaningful links. Specifically, the "self" link relation can be used as a replacement for what "url" was supposed to provide. So instead of:

{
  "objectType": "image",
  "url": "http://example.org/foo.jpg"
}

We'd use:

{
  "objectType": "image",
  "self": "http://example.org/foo.jpg"
}

The url property would still be allowed, but would be deprecated.

currently schema.org tries to address challenges related microdata not having proper support for inverse properties: https://www.w3.org/wiki/WebSchemas/InverseProperties

JSON-LD and RDFa support it nicely with

• @reverse - http://www.w3.org/TR/json-ld/#reverse-properties
• @Rev - http://www.w3.org/TR/rdfa-syntax/#iri-object-resolution

RFC 5988 states

The "rev" parameter has been used in the past to indicate that the
semantics of the relationship are in the reverse direction. That is,
a link from A to B with REL="X" expresses the same relationship as a
link from B to A with REV="X". "rev" is deprecated by this
specification because it often confuses authors and readers; in most
cases, using a separate relation type is preferable.

and HTML5 removes rev https://blog.whatwg.org/the-road-to-html-5-link-relations#rel-author

We could clarify AS2.0 strategy here, for example as:result makes a lot of sense to me as inverse property - relevant schema.org example http://lists.w3.org/Archives/Public/public-vocabs/2014Sep/0112.html

{
    "@id": "https://wwelves.org/__perpetual-tripper/bookmarks/__dfaf8a0fd9",
    "@type": "Bookmark",
    "about": "http://example.net",
    "@reverse": {
        "result": {
            "@id": "https: //wwelves.org/perpetual-tripper/activities/s0dfa091",
            "@type": "BookmarkAction"
        }
    }
}

See: https://www.w3.org/wiki/Socialwg/Social_Vocabulary

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#verb-objecttype

A Verb is a subclass of Object used to specifically describe metadata associated with an Activity verb identifier.

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html#dfn-verb

Describes a Verb.

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html#dfn-verb-term

Identifies the type of action represented in the Activity

Looking at http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#actions
I understand that we allow specifying type of Activity/Action in two ways, by using @type and its alias objectType, which seems straight forward to me and matches design of schema:Action. But also with as:verb which I understand comes from AS1.0

I don't understand benefits of using as:verb for defining type other than backwards compatibility with AS1.0 #14 IMO doing it in both ways can make logic of processing AS objects more complex. When using sub types, we also have additional possibility of defining extra properties for specific subtypes, for example http://schema.org/MoveAction extends generic action with schema:fromLocation and schema:toLocation. What about cases when someone uses both on same object, specifying @type as some specific sub-type and also providing verb?

as:Activity specifies target
http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#activities

as:ViewActionHandler also specifies target
http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-actions.html#viewActionHandler

IMO it can possibly cause confusions and prevents consistent use of as:target

This issue comes from observation I made on mailing list
http://lists.w3.org/Archives/Public/public-socialweb/2014Sep/0143.html

I see it also relevant to hydra:Link and hope that @lanthaler could support us in clarifying it
http://www.hydra-cg.com/spec/latest/core/#adding-affordances-to-representations

Looking at examples from @jasnell original email
http://lists.w3.org/Archives/Public/public-socialweb/2014Sep/0139.html

  "actor": {
    "@type": "urn:example:objectType:person",
    "displayName": "Sally"
  }

  "actor": {
    "@type": "http://activitystrea.ms/2.0/Link",
    "@id": "http://example.org/profiles/sally",
    "mediaType": "text.html"
  }

As I understand it

• first states that actor has @type urn:example:objectType:person
• second states that actor has @type as:Link

Next example which 'mixes' first two

  "actor": [
    {
      "@type": "urn:example:objectType:person",
      "displayName": "Sally"
    },
    {
      "@type": "http://activitystrea.ms/2.0/Link",
      "@id": "http://example.org/profiles/sally",
      "mediaType": "text.html"
    }
  ]

I could interpret it as: two actors, first one (blank node!) has type urn:example:objectType:person second one (node identified by IRI) has type as:Link

I get quite confused if I try to 'mix' it differently, similar as in one of my emails on that thread:
http://lists.w3.org/Archives/Public/public-socialweb/2014Sep/0141.html

 "actor": {
   "@type": ["urn:example:objectType:person", "http://activitystrea.ms/2.0/Link"]
   "displayName": "Sally",
   "@id": "http://example.org/profiles/sally",
   "mediaType": "text.html"
}

which for me states that person name Sally has mediaType "text.html"

I must admit that I feel confused about such 'mixing' of types like schema:Person and as:Link.

While hydra:Link gets defined as:

{
  "@id": "hydra:Link",
  "@type": "hydra:Class",
  "comment": "The class of properties representing links.",
  "label": "Link",
  "subClassOf": [
    "hydra:Resource",
    "rdf:Property"
  ],
  "status": "testing"
}

as:Link has definition:

{
  "@id": "as:Link",
  "@type": "owl:Class",
  "rdfs:subClassOf": "owl:Thing"
}

I have impression that defining hydra:Link as subClassOf rdf:Property and using it this way might make some significant difference...
Possibly also relevant to my email about using object keys in JSON-LD

• http://en.wikipedia.org/wiki/Open-world_assumption
• http://en.wikipedia.org/wiki/Closed-world_assumption

Paragraph bellow gives me impression of possibly taking closed world assumption. I may interpret it completely different then intended by author, so I would like to clarify which assumption this spec follows.

When serialized, absent properties are represented by either (a) setting the property value to null, or (b) by omitting the property declaration altogether at the option of the publisher; these representations are semantically equivalent. If a property has an array value, the absence of any items in that array must be represented by omitting the property entirely or by setting the value to null.

-- http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#syntaxconventions

reported by @kidehen via twitter

• https://twitter.com/kidehen/status/567654832937648129

https://github.com/jasnell/w3c-socialwg-activitystreams/blame/master/activitystreams2.owl#L1325-L1326

maybe i am reading the tables wrong, but shouldn't http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html#dfn-verb say that there is a "post" very defined by the spec itself (and that all other verb values MUST be URIs)?

http://www.w3.org/TR/2014/WD-activitystreams-vocabulary-20141023/
currently doesn't link to
http://www.w3.org/TR/2014/WD-activitystreams-core-20141023/

based on: http://lists.w3.org/Archives/Public/public-vocabs/2014Nov/0009.html

How do you see
http://www.w3.org/TR/2014/WD-activitystreams-vocabulary-20141023/ ?

I don't see how to understand this document without having access to the
Activity Streams 2.0 Core document. After quite a bit of work, I found what
appears to be an editors' draft of that document at
http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html

JSON-LD's media type has a profile parameter which would allow to convey the same information as a separate media type. The processing model of application/ld+json isn't changed but the document conforms to a couple of additional restrictions which are defined by the profile.

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-actions.html#dfn-type

Specifies the expected data type of the parameter. The value should specify a type from the XML Schema Data Types.

I would suggest using name as:dataType similar to as:mediaType and as:objectType.

While JSON-LD uses @type also for Typed Values of Literal nodes, IMO defining as:type as Data Type can cause some confusion.

http://www.w3.org/TR/json-ld/#typed-values

Currently, AS collections must use a JSON array (http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/#collections). This can be cumbersome and problematic for scenarios with streaming activity data, and/or very large collections. One possibility would be to also allow JSON text sequences https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/, which probably very soon will become a stable RFC. Since they have their own media type, standard HTTP mechanisms could be used between a client and a server to negotiate the supported/preferred format for collections.

I just tried parsing example Action using provided Non-Normative JSON-LD @context. We can see results on JSON-LD Playground

{
  "@id": "http://example.org/cats.mpg",
  "http://activitystrea.ms/2.0/actions": [
    {
      "@index": "embed",
      "@value": "http://example.org/gadgets/video.xml?v=cats.mpg"
    },
    {
      "@index": "embed",
      "http://activitystrea.ms/2.0/content": "<video ... />",
      "http://activitystrea.ms/2.0/objectType": "inline-html"
    },
    {
      "@id": "http://example.net/share",
      "@index": "share",
      "http://activitystrea.ms/2.0/displayName": "My Sharing Service",
      "http://activitystrea.ms/2.0/objectType": "service"
    },
    {
      "@index": "watch",
      "@value": "movie://example.org/cats.mpg"
    }
  ],
  "http://activitystrea.ms/2.0/objectType": "video"
}

I would like to help with automating parsing all examples as JSON-LD and verifying if they match hand written expected results.

Many social systems use a in-band mechanism to let users define a category or topic for an object. For example, "#topic" will mark an image or text as being related to the topic "topic".

It would be worthwhile to note that Activity Streams 2.0 processors should not have to parse the "content" or other properties of activity objects to determine this category information.

Instead, the stream creator SHOULD add a "tag" property to the object and MAY change the "#topic" content to a link to a page about that topic (for example, one showing a stream of all objects related to that topic).

Fix microformats examples in spec to reflect actual minimal standard publishing / consuming practices, specifically to incrementally address https://www.w3.org/Social/track/actions/26

While reviewing the microformats examples I've found patterns of problems to fix that will likely apply to most if not all existing microformats examples in the spec.

This is issue is for documenting all of these issues in general, and I expect to submit multiple pull requests to fix specific instances of these problems.

Problems and fixes

• use "h-entry" instead of all the "h-as-*" class names
• use <a class="p-author h-card" href="http://martin.example.org/">Martin</a> instead of <link class="u-author" href="urn:example:person:martin">Martin</link>
• use <img class="u-photo" href="http://martin.example.org/foo.jpg" alt="Photograph of foo"/>
  instead of <a class="u-item" href="http://example.org/foo.jpg">"http://example.org/foo.jpg"</a>

Use

<a class="p-author h-card" href="http://martin.example.org/">
<img src="http://martin.example.org/image.jpg" alt=""/>Martin Smith
</a>

instead of:

<div class="p-author h-card">
<meta class="p-as-id" name="id" content="urn:example:person:martin" />
<a class="u-url p-name" href="http://example.org/martin">
Martin Smith
</a>
<img class="u-photo" src="http://example.org/martin/image.jpg" type="image/jpeg" />
</div>

Use

< a class="u-url p-name" href="http://martin.example.org/blog/2011/02/entry">
Why I love Activity Streams
</a>

instead of:

<div class="p-item h-entry">
<meta class="p-as-id" name="id" content="urn:example:blog:abc123/xyz" />
<a class="u-url p-name" href="http://example.org/blog/2011/02/entry">
"Why I love Activity Streams"
</a>
</div>
To
<div class="p-as-target h-entry">
<meta class="p-as-id" name="id" content="http://example.org/blog" />
<span class="p-name">Martin's Blog</span>"
</div>

• use <time class="dt-published" datetime=" instead of <meta class="dt-published" name="published" content=" including /time instead of /meta.

This is just a start, I'll add more as I find more.

Currently most terms have range set to
"rdfs:range": ["as:Object", "as:Link"]

I would see need for non-normative section eleborating on consequences of using one or the other. IMO many developers can find it confusing to face such choice and make such decision without realizing consequences. Also it may make sense to recommend implementations to expect and handle properly both.

Maybe we could use example from Link section

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "urn:example:types:application",
  "image": [
    "http://example.org/foo.jpg",
    {
      "@type": "http://www.w3.org/ns/activitystreams#Link",
      "href": "http://example.org/screens/1.jpg",
      "rel": "preview",
      "mediaType": "image/jpeg"
    }
  ]
}

with alternative

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "urn:example:types:application",
  "image": "http://example.org/foo.jpg",
  "preview": {
    "@type": "urn:example:types:image",
    "@id": "http://example.org/screens/1.jpg",
    "mediaType": "image/jpeg"
  }
}

http://www.w3.org/TR/2015/WD-activitystreams-vocabulary-20150129/#activity-types

defines Offer and Give, while sometimes we need the inverse types e.g.

• https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Offering_asparagus
• https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Demanding_help_with_the_harvest

do we have strategy for such cases?

schema.org has couple of defined ones: http://schema.org/docs/search_results.html#q=Reciprocal

See discussion at http://lists.w3.org/Archives/Public/public-socialweb/2014Oct/0025.html

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html#dfn-status

An optional, explicit indicator of the current status of the activity. "http://activitystrea.ms/2.0/status/active" indicates that the activity is ongoing, "http://activitystrea.ms/2.0/status/canceled" indicates that the activity has been aborted, "http://activitystrea.ms/2.0/status/completed" indicates that the activity has concluded, "http://activitystrea.ms/2.0/status/pending" indicates that the activity is expected to begin, "http://activitystrea.ms/2.0/status/tentative" indicates that the activity has been proposed, and "http://activitystrea.ms/2.0/status/voided" indicates that the activity has been retracted or should be considered invalid.

we could take similar approach as in http://schema.org/ActionStatusType
which defines 3 enumeration members

also when read by human, using UpperCase Active, Canceled, Completed, Pending, Tentative and Voided can make clearer distinction from lowerCase predicates. current vocab already takes this approach and this IMO would make it even more consistent

Schema.org uses only singular names for properties, as described in:
https://www.w3.org/wiki/WebSchemas/Singularity
this page also links to email by @tantek
http://lists.w3.org/Archives/Public/public-vocabs/2012Mar/0016.html

AS2.0 Vocab suggests mixed (singular/plural) naming: participant, author, provider, rating, replies, attachments, actions ...

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html#dfn-alias

Provides a contextually meaningful alternative label for the object in addition to the id. For instance, within some systems, groups can be identified by both a unique global identifier and a more "human-friendly" label such as "@friends" or "@network". The value of the alias property must match either the isegment-nz-nc or IRI productions in [RFC3987]. The use of a relative reference other than a simple name is not allowed.

currently i find only one example in: http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#verb-objecttype

A Verb is a subclass of Object used to specifically describe metadata associated with an Activity verb identifier.
Fig. 14 For instance, the following describes the "urn:example:verbs:upload" verb identifier:

{
  "@type": "http://activitystrea.ms/2.0/Verb",
  "@id": "urn:example:verbs:upload",
  "displayName": "Upload",
  "alias": "upload"
}

but any as:Object can use it not only as:Verb

I would see more examples helpful to understand intended usage. Also we may need to clarify how it relates to JSON-LD aliasing available via @context

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#audienceTargeting

Every Activity has both a Primary and Secondary audience. The Primary audience consists of those entities either directly involved in the performance of the activity or who "own" the objects involved. The Secondary audience consists of the collection of entities sharing an interest in the activity but who are not directly involved (e.g. "followers").

what we consider an audience? other people, groups, circles, lists of contacts ...

There were some additional properties added speculatively to the AS2 vocabulary earlier on it's it's dev cycle that are proving less than generally useful. There's also a couple carry overs from AS1 that ought to be deprecated.

1. The valid* properties. These were intended to offer a date-based validity bound for an Object's metadata. While useful, these can easily be provided as an extension where necessary. They are not generally useful for all objects and have a questionable processing model since we do not define exactly what "validity" means. These just just be removed.
2. The status property on Activity. This was one was added earlier in the AS2 dev cycle (pre-WG) and was always very speculative and has proven less than useful. This one should just be removed.
3. The existing "author" property on objects. This is a carryover from AS1. Not all objects have authors and there's a confusing overlap between "actor" and "author". This one should be deprecated but still allowed.

The current 2.0 draft includes a broad range of optional attributes. As far as I can tell, many implementers use these but no two seems to use the same set. We can simplify the core document by moving all of the optional bits out into their own separate document and JSON-LD @context. The optional attributes would still be defined, but the core spec would be greatly simplified.

During our last telecon @jasnell mentioned a design choice motivated by intention to keep backward compatibility with AS1. I would find it useful to understand what other design choices come out of this motivation.

jasnell: JSON-LD implies both the JSON syntax and a particular
processing model, and the @id kind of stuff. For backward
compatibility, AS2 did not go there.
... AS2 does not say that it is JSON-LD, but here is a set of
guidelines for how to process it as JSON-LD.
... Important distinction
elf-pavlik: i understand backward compatibility to AS1

-- https://www.w3.org/wiki/Socialwg/2014-09-09-minutes

• not requiring IRI for values of as:verb #23 (comment)