Re: AS2 media type

Hi Robert,

On 10/20/2015 01:07 PM, Robert Sanderson wrote:
> James, Elf,
> 
> Some hopefully middle ground in the suggestions below, from similar
> discussions in the Annotation group:
Thank you for helping us with searching for a middle ground, very much
appreciated! From my side just few comments inline:

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

I would expect variants of below in more than 1% of real world scenarios

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    "vcard": "http://www.w3.org/2006/vcard/ns#"
  ].
  "@id": "https://bob.example/",
  "vcard:hasEmail": { "@id": "mailto:mail@bob.example" }
}


{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    "email": {
      "@id": "http://www.w3.org/2006/vcard/ns#hasEmail",
      "@type": "@id"
    }
  ].
  "@id": "https://alice.example/",
  "email": "mailto:alice@bob.example"
}



> 
> So ... +1 to requiring compact form... and to expressing that as part of
> the constrains in the profile.
I would like to see some concrete use cases which require compacted
form, preferably links to source code in some open source lib / app.


> 
> 
> 
>>>   (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.
+1 reuse existing common terms by aliasing them in JSON-LD context



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

maybe profile="http://www.w3.org/ns/activitystreams" ?

Cheers!

Received on Tuesday, 20 October 2015 13:24:19 UTC