- From: elf Pavlik <perpetual-tripper@wwelves.org>
- Date: Tue, 20 Oct 2015 17:19:23 +0200
- To: James M Snell <jasnell@gmail.com>
- CC: "public-socialweb@w3.org" <public-socialweb@w3.org>, Sarven Capadisli <info@csarven.ca>
On 10/20/2015 04:57 PM, James M Snell 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. Thank you for reminder James, since Social API spec very unlikely will make AS2.0 (application/activity+json) a MUST, and more likely a SHOULD or even just MAY, possibly we actually put way too much importance on trying to agree on all those things... > > 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 15:19:33 UTC