Re: AS2 media type

On 20 October 2015 at 16:57, James M Snell <jasnell@gmail.com> wrote:

> Let's also not forget that the Activity Streams 2.0 Core and Activity
> Vocabulary documents are two separate things. The former defines the
> JSON-LD derived serialization while the latter defines the vocabulary
> model. If an implementer so chooses, there is absolutely nothing in
> the Activity Vocabulary spec that requires use of the specific
> serialization defined in the AS 2.0 Core document. If an implementer
> so chooses, they can use the Activity Vocabulary inside "normal"
> JSON-LD and RDF applications using the `application/ld+json` media
> type and requiring full RDF style processing. Such documents would be
> valid uses of the Activity Vocabulary but would not be Activity
> Streams 2.0 Documents per se -- which is a perfectly valid and ok
> thing to do -- just like how using the Activity Vocabulary in RDFa or
> Microdata is a perfectly valid and ok thing to do but we wouldn't call
> HTML that includes Activity Vocabulary data and Activity Streams 2.0
> Document either.
>

Thanks James, I think you've raised a number of good points.

Regarding the question as to :

1. New mime type
2. Reuse existing mime type + profile parameter

it would be good to establish how strongly you feel on this issue.  I think
there are legitimate arguments on both sides.

A new mime type would incur extra work, and would need to go through an
approval process.  Both the W3C and IANA would need to accept it.  There
may also need to be a file extension specified.  Granted, there are
generally low bars for acceptance at iANA.  And there is a precedent for
W3C publishing work with a JSON serialization that is not JSON LD, namely
RDF/JSON

https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html

Tho perhaps there would need to be some accompanying text to explain to
readers the relationship with JSON LD.

My thought is that going the JSON LD route + profile parameter incurs no
extra work from a standardization perspective.  A new mime type would incur
extra work and it would be good to hear how much of a show stopper this
issue is before closing it.


>
> On Tue, Oct 20, 2015 at 6:52 AM, James M Snell <jasnell@gmail.com> wrote:
> > Elf,
> >
> > I've answered your questions about Curie expansion already. I'm not
> going to
> > answer them again.
> >
> > Your concerns about as:Link have been brought up previously, discussed,
> and
> > the group decided to keep the current model. I will not be revisiting
> that
> > discussion.
> >
> > The discussion over requiring the compact form happened over a year ago.
> I
> > will not be revisiting that discussion either.
> >
> > The conversation happening right now is about the media type.
> >
> > - James
> >
> > On Oct 20, 2015 3:33 AM, "elf Pavlik" <perpetual-tripper@wwelves.org>
> wrote:
> >>
> >> Hi James,
> >>
> >> On 10/20/2015 12:00 AM, James M Snell wrote:
> >> > On Mon, Oct 19, 2015 at 2:45 PM, Sarven Capadisli <info@csarven.ca>
> >> > wrote:
> >> > [snip]
> >> >>
> >> >> What breaks when you reuse the existing media types?
> >> >>
> >> >> 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. Non AS2 specific
> >> clients will not have possibility to find it, which will limit audience
> >> of data published this way. IMO using profile parameter seems to work
> >> for all clients, those who know about AS2.0 specific processing and
> >> those which will do their best by interpreting i as JSON-LD
> >>
> >>
> >> >   (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.
> >>
> >> >   (c) that all date/time values use ISO8601 format
> >> https://tools.ietf.org/html/rfc7493#section-4.3
> >>
> >> >   (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
> >>
> >> >   (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*
> >>
> >>
> >> >   (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
> >>
> >>
> >> >
> >> > Using "application/ld+json" does not communicate to a receiver any of
> >> > these additional constraints.
> >> >
> >> > 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.
> >>
> >>
> >> >
> >> > - James
> >>
> >> I apologies if I sound impatient in this email, I just have impression
> >> that after a year of working on it 'kind of together' we keep walking in
> >> circles :(
> >>
> >> Cheers!
> >>
> >
>
>