Re: ActivityStreams Schema: Hierarchy of Types

You say "I'd welcome rebases onto other wide-ranging vocab-sets! I've
stated that." but you only seem to want to consider and you
downright laugh at vCard and thus microformats and the semantic web. That's
silly considering their specifications are used by many social web systems
(if you don't believe me just say the opposite to Tantek and wait 1 second
for a response :) and is used to build a distributed/federated
social web app by... I can't think of one.

vCard, vEntry, etc, won't be thrown into json, as you noted seemingly in
horror, as far as I can tell it will be mapped to a corresponding field.
You'll be able to pull out the same information if it exists in the
activity, probably automatically.

Anyway, has overlap, as has been mentioned, are aware of the
working group, and there will be collaboration to maintain a mapping from
the concepts of activity streams to to allow for proper interop.
They don't have a clear means of contribution and they wish to have
authoritative control over their ontology of terms. If this working group
wants the autonomy to handle its use-cases, I believe it would want to
avoid dealing with that. It was agreed with the working group to look at, but not use them outright because of this, which makes
tremendous sense.

Essentially, though, as you said is trying to map a universal
vocab. In my opinion, they do that because they have centralized interests
at heart. Frankly, there is no such thing as a universal vocab.
Extensibility will hopefully win instead of their world-view. The base of
activity streams just needs to be a small set of very conventional concepts
that can be extended and discovered, not curated, bur rather having their
meaning be determined by their use. And then having an extended vocab with
common objects (notes, images, etc) would be good to start from, but you
don't enforce that as the Only things in existence and allow other people
to contribute to your ontology transparently. We need to get away from the
idea of controlling the ontology and with as a base,
particularly one we don't control, mixed with's perceived
autocracy, well, that would present some trouble.

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.

How can people think Atom is considered the underlying thing for activity
streams? Haha. You could throw namespaced activities into Atom in AS1, but
it's mostly just the AS1 Atom spec in particular that simply maps AS on top
of Atom/PortableContacts. It's a smart idea having AS1's XML serialization
fallback to Atom which could fallback to RSS. This is again strange because
you say "I have yet to see how far [this working group] can get rebasing
onto more general technologies."

It'll be fine. We'll have the basic blocks with minimal semantics and an
API to move those blocks around, and then implementers will worry about
What These Blocks Mean. ActivityStreams is great for this (once Actions are
more extensible and discoverable). It'll be good.

On Mon, Nov 10, 2014 at 4:02 PM, <> wrote:

> On Fri, Nov 07, 2014 at 11:43:55PM +0000, Owen Shepherd wrote:
> > > <>
> > >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 <
> >,
> > and in fact predates 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
> > really seems quite silly. After all, the organizations
> > which invented were heavily involved in ActivityStreams
> > 1.0, including the definition of the Avtivity Base Schema.
> >
> > You cite exclusively,
> I'd welcome rebases onto other wide-ranging vocab-sets! I've stated that.
> > which we have excluded for the
> > following reasons:
> >
> > 1. is not produced by any standards organization, nor does
> >    it have any defined open contributor model. While the organizations
> >    behind 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. 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 lacking. The
> >    design of 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, doesn't offer
> has significantLink which can declare
> rel-typed
> links.
> > >>          + ...
> > >>      o as:Group
> > >Missing. doesn't quite fit-- too big a
> concept.
> > Right. 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 that it is the
> > one core vocabulary for everything.
> Lack of 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
> >, and we may have some agreement on alignment there (i.e.
> > 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?
> is an RFC, but it stems from nothing.
> RFC certainly does not meet the standard you set out for 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.
> 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:46:06 UTC