Re: social-ISSUE-16 (grammar/vocabulary): better separate grammar/vocabulary and improved spec structure [Activity Streams 2.0]

On 03/02/2015 10:55 AM, Social Web Working Group Issue Tracker wrote:
> social-ISSUE-16 (grammar/vocabulary): better separate grammar/vocabulary and improved spec structure [Activity Streams 2.0]
> 
> http://www.w3.org/Social/track/issues/16
> 
> Raised by: Erik Wilde
> On product: Activity Streams 2.0
> 
> hello.
Hi Erik!

> 
> i have a proposal for improving the AS 2.0 spec structure in the sense that the spec structure better aligns with developer expectations, will become easier to read and implement, and maybe also provides a cleaner path to define and support an extension model.
> 
> - what's currently called "core" classes/types (http://www.w3.org/TR/activitystreams-vocabulary/#types) should become part of the basic AS model that is defined by the current AS core WD. after all, this is the "grammar" of AS, it's what establishes the basic resources of AS, and the ways in which these are establishing the AS resource model, and how it is serialized.
IMO WG should focus on that core, especially that we still have a lot of
ISSUES and ACTIONS open for most of the core classes/types

*Link*
* ISSUE-14: as:Link adds a lot of complexity, if we keep it we need to
clarify consequences of using it instead of as:Object
* ACTION-42: MediaObject - gather options for its social syntax on a
wiki page

*Actor*
* ISSUE-17: Identity, Agent, Person, Persona, Account etc. need
clarifications

*Collection*
* ACTION-44: Collection - compare AS2 design with LDP, Hydra, Schema.org
etc.

*Object*, *Activity* and *displayName* already look pretty solid!


> 
> - what's currently called "extended" classes/types (http://www.w3.org/TR/activitystreams-vocabulary/#extendedtypes) should become the only content of the "vocabulary" spec and should be called "core vocabulary", because that's the common/shared vocabulary of AS that's supposed to be shared across (all or at least the vast majority of) implementations.
> 
It makes a lot of sense to me that IG focuses on Vocabulary work, as its
charter states. Social IG would deliver Extended Vocabulary and then
work with various other W3C groups on *Domain Specific* vocabularies. e.g.
* Social Business CG & Web Payments IG/CG
Online Marketplaces vocab (Offer, Demand, Transaction etc.)
* Collaborative Software CG & Decisions and Decision-Making CG -
Groupware vocab (Issue, Action, Task etc.)
* Games CG - Games vocab (Game, Score, Player etc.)
* Council CG & Zakim on Web CG
W3C Collaboration vocab (Scribe, Chair etc.)
* etc.


> here are the reasons for this proposal:
> 
> - we should clearly separate they fundamental model (resources and their grammar) of AS, and vocabularies using this model. currently, the former is split across two specs, and the latter is not self-contained in its own spec.
> 
> - the AS 2.0 core vocabulary (according to the proposed new terminology) should provide a good and direct blueprint for people creating their own vocabularies. they should be able to take the vocabulary spec and use it as a template very directly.
> 
> this should give us a better path towards a clean and well-defined extension model, which in essence should tell:
> 
> - developers how to define additional vocabularies, and most importantly, what kinds of things they can define in those vocabularies, and
> 
> - users one way how to learn about additional vocabularies, should the developers choose to document them in the way proposed by us.
> 
> our goal is to have a clean extension model, and to have a well-defined and well-documented way in which vocabulary developers can use that extension model. we are working on a model that is definitely inspired by james' work on AS 1.0 "Verb Definitions for Activity Streams" https://raw.githubusercontent.com/activitystreams/activity-streams-verb-definition/master/activity-streams-verb-definition.txt, with the eventual goal of having some kind of "AS Schema Language" that allows the sharing of information *about* AS.
> 
> if there are other having the same interests (going beyond the built-in schema), it would be great to hear about their plans and ideas for how to best set up the current spec structure to better separate grammar and vocabulary, and eventually how to actually define those vocabulary extensions.
> 
> thanks and cheers,
Thanks for these suggestions, makes a lot of sense to me!


> 
> dret.
> 
> 
>