Re: AS2 media type

James, Elf,

Some hopefully middle ground in the suggestions below, from similar
discussions in the Annotation group:

On Tue, Oct 20, 2015 at 11:23 AM, elf Pavlik <perpetual-tripper@wwelves.org>
wrote:

> >> How are the existing media types insufficient to AS2's needs?
>
> > Among other things, AS2 requires:
> >   (a) the use of a normative @context definition;
> This requires *all* clients to have 'hard coded' knowledge about
> existence and location of that normative context.


Most clients will ignore the media type all together and rely on out of
band knowledge of the representation structure provided from the URL.  No
one checks the media type of responses from twitter or facebook to see if
they've suddenly changed.

That said, +1 to the profile parameter here. It gives a definitive link to
the requirements, rather than requiring knowledge up front of a new media
type but still lets you give the more explicit information... something
that has been missing for years on the web. And at the same time, will work
as expected with JSON-LD clients. Seems like a win/win... and getting it
wrong has little real cost.


>   (b) the use of JSON-LD compact form;
> IMO this can cause more interoperability problems than benefits! If
> people don't expand URIs in their code before matching them, this will
> break the whole extensibility. Property with compacted name 'ex:foo'
> from one source, doesn't equal property with the same compacted name
> 'ex:foo' from another source. One still need to expand them to full URIs
> based on mappings in ... JSON-LD context.
>

For the 99% case, I don't think this is relevant.  AS is thorough and
complete enough for its intended uses that extensibility won't be
frequently needed.  And clients that encounter an unexpected ex:foo won't
know what to do with it anyway, so expanding it to a URI won't help them.

So ... +1 to requiring compact form... and to expressing that as part of
the constrains in the profile.



> >   (c) that all date/time values use ISO8601 format
> https://tools.ietf.org/html/rfc7493#section-4.3
>


Meh.  Is there any serious system that expresses date/times NOT in an
ISO8601 compatible form? I also don't see that any particular media type
will help here anyway.


> >   (d) that the AS1 "objectType" and "id" values MUST NOT be used.
> only relevant to people who migrate from AS1 (anyone even works on it?),
> nothing to do with people starting from AS2
>

Agree this is also not especially relevant.


> >   (e) the implementations MUST treat all objects as derivatives of
> > as:Object unless the the object uses @type:as:Link
> IMO we still have some work to do with all the issues around as:Link ,
> actually it seems more relevant to API than *modeling social information*
>

Agree that Link needs additional thought and discussion, and a further -1
to normatively requiring an implementation detail like this at all.  If we
have an as:Collection of Annotations, those Annotations are not somehow
magically subClasses of as:Object, nor do they need to be treated as such.


>   (f) that AS defined terms be preferred over overlapping terms from
> > other vocabularies
> overlapping? how come? all AS terms have *unique* URIs to identify them,
> no overlap possible... unless we try to make ourselves believe that we
> can have extensibility without expending to full URIs -1
>

I understood "overlapping" to be at the semantic level.  That if you have a
choice between as:displayName, rdfs:label, dc:title and skos:prefLabel,
that AS would like you to use the AS term.

Given the requirement to use the compact JSON-LD form with all of the json
keys as expected, I find the decision to re-invent everything particularly
strange, when the context document gives an easy way to reuse while hiding
the (alleged) complexity.



> > Which means in order to communicate these additional constraints, a
> > profile parameter would need to be used, in which case you've
> > accomplished nothing more than you would by simply defining a new
> > media type.
> Again, non AS2.0 specific clients will not have a way to process data,
> even that 'behind masquerade' it uses JSON-LD which they could process
> easily.
>

Consider the damage to the web ecosystem if every version of every schema
(be that XML or JSON or whatever comes next) created a new media type. The
profile param has the advantage of being just as explicit, without further
cluttering up the media type tables, and allowing generic clients to do the
right thing with the base JSON-LD media type.

Rob

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305