separation of AS2 format and vocabulary

hello harry.

while i agree with the overall sentiment of your post, please keep in 
mind that when done the web way, there is no real (i.e., IPR-relevant) 
dependency between a rather generic format and plug-in vocabularies. 
that's the beauty (and of course the danger as well) of the web: 
identify concepts globally, and then see who's winning. no IPR 
discussion even required.

On 2014-11-11, 00:54, Harry Halpin wrote:
> Note that there would naturally be concerns for any normative dependency
> in a W3C spec on any work produced outside of a standards body. However,
> due to the lengthy discussion with the Social Web WG, earlier schema.org
> made its licensing compatible with W3C licensing and also now has some
> interest in a member submission or 'snapshot' that would be referencable
> - so soon I do think it will be possible to reference schema.org,
> although whether or not we do so is the decision of the WG. This is a
> topic the W3C is actively discussing across multiple working groups, as
> it's similar to the situation with W3C and WHATWG specs.

if we do it the way AS1 did, but cleaner, then what we have is AS2 as a 
spec for the AS information model, and AS2 as a vocabulary that would be 
a subset of 
https://github.com/activitystreams/activity-schema/blob/master/activity-schema.md 
and say which activities AS2 implementers probably should expect 
(http://localhost/github/W3C/SocialWG/AS1-in-AS2.html is a first attempt 
at managing this process of distilling an AS2 vocab from AS1).

keep in mind that in order to support AS, one does not need to 
"understand" *any* specific vocab. like evan's pump.io, an AS 
implementation only needs to pass through AS data, and only needs to 
start "understanding" activities if it wants to take action on some of 
them (such as evan's pump.io effectively exposing its "API" in the form 
of taking action on some activities).

in our implementation, we take a different approach and instead of 
having an "implict API" like evan, we have an "explicit API" that allows 
to control the behavior of the AS platform. because of that, for us any 
vocabulary is essentially opaque anyway; all we need is AS to be clear 
about how to identify certain key concepts with activities, such as 
verbs, objects, actors, and time stamps, so that we can use those for 
driving the activity flow.

so in terms of IPR issues, AS itself can steer clear of them entirely, 
which is great. then we probably should have some base set of verbs, be 
it AS1-derived or schema.org-derived, that is "recommended" to be 
supported by implementations. keep in mind though, that either way we 
go, there is no way for us to even prevent that somebody who does not 
like that choice would simply create a competing vocabulary for the 
"other side", and start using/promoting that.

> For the Social WG, I think the key would be to not replicate
> vocabularies. For example, if we have to chose between a vocabulary with
> widespread deployment by real users and a more academic vocabulary, we
> should chose the vocabulary with widespread deployment. However, we must
> also make sure we have the proper IPR commitments.

i think all we can do is is choose one that the WG is (most) happy 
about, and then set that free as the WG-endorsed vocabulary. if some 
other vocabulary is released and gains momentum, there's actually very 
little we can do to prevent that from happening. which is very good.

> Also, note that vocabularies in general are in the scope of the Social
> Interest Group, not the Working Group and we'd expect the Working Group
> to only adopt the most minimal vocabularies possible needed for its
> deliverables, with other vocabularies (such as those around profiles)
> being standardized elsewhere in either the W3C or outside the W3C.

that's good and definitely the right approach, but for that minimal 
vocabulary, we probably still have to make the choice to go with an 
AS1-derived one, or a schema.org-derived one.

one thing we maybe should discuss would be to avoid the separation we 
now have between AS2 the format and the AS2 base vocabulary, and make 
the base vocabulary a required and integrated part of the spec. that way 
we would make sure there is a unified set of verbs everybody is required 
to understand, but we then would have to make sure that all potential 
IPR issues are resolved. but in that case, i would actually recommend to 
take s snapshot of what we think is a good set, and make that a part of 
AS2 itself, instead of just pointing to some external definition and 
create what optimists would call a "living standard", and pessimists 
would call a "moving target".

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, 11 November 2014 08:37:02 UTC