Re: ActivityStreams Schema: Hierarchy of Types

On Fri, Nov 07, 2014 at 11:43:55PM +0000, Owen Shepherd wrote:
> >rektide@voodoowarez.com <mailto:rektide@voodoowarez.com>
> >07 November 2014 23:03
> >It's highly disappointing to me to see this working group continue
> >to run away from the existing vocabulary projects out there and work
> >to define it's own vocab. There is so much important work to be done
> >surrounding use cases, yet this group is literally back to square 0,
> >defining vocabs.
> None of this is really defining a new vocabulary. It is renewing a
> vocabulary which already exists <https://github.com/activitystreams/activity-schema/blob/master/activity-schema.md>,
> and in fact predates Schema.org. The "actually" interesting things
> here are the extra types introduced between "object" and the more
> specialized types to cover the implicit typing present in AS1.
> 
> If one wants to talk of going back to square 0, then bringing up
> schema.org really seems quite silly. After all, the organizations
> which invented Schema.org were heavily involved in ActivityStreams
> 1.0, including the definition of the Avtivity Base Schema.
> 
> You cite exclusively Schema.org, 

I'd welcome rebases onto other wide-ranging vocab-sets! I've stated that.

> which we have excluded for the
> following reasons:
> 
> 1. Schema.org is not produced by any standards organization, nor does
>    it have any defined open contributor model. While the organizations
>    behind Schema.org do accept contributions, they hold veto powers
>    over any modifications

This is an immensely damning argument which I have no reply to. They've
proven that they are interested in taking good work and using it, but
their lack of accountability is troubling in the extreme and in the future
that could lead to enormous problems that warrant abandoning them as a base.

> 2. Schema.org alone is not sufficient for our use cases

I don't see that this is relevant. In Linked Data it is enormously easy to
supplement in cases where the base is found lacking.

> 3. Several of us find the technical quality of Schema.org lacking. The
>    design of Schema.org contains numerous things which are illogical
>    and badly designed.

It's enormously hard for me to find a place to begin to suggest constructive
ways forwards from this declaration of popular sentiment.  I see it mirrored
among others in this working group, but I'm thoroughly ignorant as to what
has caused these feelings of lack and insufficiency. 

I'm sure some of ya'll have laundry lists of complaints; I'd like to see them
to see how many are real and incapable of being worked around.

For now, it feels like there's just a bunch of cranks bearing no responsibility
in exercising their disposition against what others feel like is a start for a
universal vocab.

> >>          + as:Collection
> >You don't get json do you? Json is all over your charter. Just use an array.
> You clearly have not paid attention to ActivityStreams collections.
> My inbox should not be a JSON array. ActivityStreams collections are
> paged.
> 
> Something, which as far as I can tell, Schema.org doesn't offer

http://schema.org/CollectionPage has significantLink which can declare rel-typed
links.

> >>          + ...
> >>      o as:Group
> >Missing. https://schema.org/Organization doesn't quite fit-- too big a concept.
> Right. Schema.org is not focused on the social use case. It doesn't
> contain features we need, and it is not extensible. At least, not
> without giving up the key reason to use Schema.org: that it is the
> one core vocabulary for everything.

Lack of schema.org doing everything you want is not imo a valid argument. Linked
Data makes it trivial to supplement their base with things you need. 'Actions'
have indicated that they are willing to adopt new elements. 'All or Nothing'
is a false argument here: it is refusal to work with anyone who has not
anticipated all possible desires you might have. And that justification is
core to what I see as this going-it-alone-ness that the working group is actively
pushing itself towards.

> >>This then gives us a basis for declaring common properties (e.g. a
> >>Person doesn't have comments, but all content objects do)
> >>
> >>Thoughts?
> >
> >I would like to see this working group work with others and focus on apis
> >and use cases for objects, rather than reinventing particular protoforms
> >for specfici objects.
> We do work with others. We are actively communicating with the
> Annotations WG, with whom we have significant overlap. We are
> reaching out to the various related projects which we feel should be
> directly involved in this work. We have had discussions with
> Schema.org, and we may have some agreement on alignment there (i.e.
> Schema.org actions and ActivityStreams actions should have a 1:1
> mapping to each other and share a data model, even if they have
> different names). I'm pretty sure we have some informal consensus
> that vCard and iCalendar will be explicitly included in the list of
> vocabularies to be used with ActivityStreams and mapped
> appropriately.

Ugg in bed with the semantic hasBeens, working to justify their ancient
mess of OWLs. We want PRODID and DTSTAMP and TRIGGER to be the legacy
cruft that powers Activity Streams? VEVENT VALARM are going to be hauled
into JSON somehow?

https://tools.ietf.org/html/rfc5545 is an RFC, but it stems from nothing.
RFC certainly does not meet the standard you set out for schema.org above,
as guided by an organization with an open participation model. But mostly
I think it dangerous to adopt an event model where events might not share
terminology with other specs.

http://schema.org/Event at least stems from a common underlying Thing, and
is built in a world where an attendee person can be linked-data: a place
that iCalendar never considered.

> No vocabulary (besides AS1 plus a couple of extensions) encompasses
> our use case - and some of the vocabulary elements are going to be
> driven directly by the needs of implementing a social protocol.

This perception that your use case is inherently special and different is
the anti-social kernel i see as so faulty here. I have yet to see this
work-group actually try to migrate off the 2011 1.0 spec and to see
how far it can get rebasing onto more general technologies.

> The core of AS2 is shaping up to be a really nice vocabulary really
> quickly, and the extended portions are things we can easily model
> based upon experience. There are just one or two pieces of the core
> vocabulary which are proving controversial and "bikesheddy".

It's based off a conception made around early 2010's deriving heavily from
work put into play in Atom.

I'd like to see some honest reassessment made that perhaps Atom is not
qualified to underly everything. Yet the pennon of 'social specs for 
social' is carrying this WG, with no test of that assertion that carries
this 2000's standalone tech forward and along.

Received on Monday, 10 November 2014 21:02:55 UTC