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

hello elf.

On 2015-03-09 22:52, ☮ elf Pavlik ☮ wrote:
> 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]
>> - 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.

so far i don't see a clear definition on how they're supposed to define 
those vocabularies, and what behavior they can expect from AS 
implementations. can they define a "floop" and expect it to be handled 
as a "like" reliably? if not, what sense does it even make to be able to 
say that a "floop" *is a* "like", when this does not lead to predictable 
behavior of AS implementations?

since AS2 is in flux, we're still using AS1 for our platform, and we've 
recently started to better formalize the way in which we define and 
implement extensibility. if anybody is interested, here's a link:

https://github.com/dret/ASDL

AS2 can do this differently (and i am sure that many will jump to the 
conclusion that this of course should be done in RDF, which is certainly 
one possibility among others), but i think most importantly, AS2 has to 
do it, and it currently isn't.

>> 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!

that's good to hear. i think we really have to tackle these issues very 
aggressively. they are not trivial to address well, there are many 
design paths we could choose, and writing up whatever we choose to do 
also will take a bit of time.

i still think that restructuring the specs to better reflect the design 
into the core, the base schema, and maybe one example extension schema 
would be tremendously helpful for AS developers. when we're done, they 
will have to figure out what the core AS model is, what the base 
vocabulary is, and how they can define their own extensions. they should 
also have a definition of what behavior they can expect in ecosystems 
where different implementations will support different extensions, but 
they are supposed to interact in predictable ways.

thanks and cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Tuesday, 10 March 2015 08:29:33 UTC