Re: AS2 media type

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.

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!
>>
>

Received on Tuesday, 20 October 2015 14:58:14 UTC