Re: internationalization issues

I have been working on ways to get AS2 compatible output from my site,
and I don't think I can generate a valid context for the document as
various terms I use on the site (some from microformats-2, some from
IWC's wiki, and some my own vendor prefixes).

The other problem has been, as others have mentioned, that the various
ways to represent a key in JSON-LD (aliasing being a primary one)
means you cannot just ignore the context as I have been told.  If you
just ignore context or only process part of it, you can easily end up
with values that appear to have different keys when they are not.

One way forward I would suggest is that we drop conformity to JSON-LD
from the spec.  So long as it can be converted in a non-lossy way to
JSON-LD, it should be an easy task for those wishing to use it as
such.  This would free us of any limitations of the JSON-LD spec.

On Fri, Oct 23, 2015 at 3:35 PM, Owen Shepherd <owen.shepherd@e43.eu> wrote:
> On Fri, Oct 23, 2015 at 9:41 AM elf Pavlik <perpetual-tripper@wwelves.org>
> wrote:
>>
>> On 10/22/2015 07:46 PM, Harry Halpin wrote:
>> > However, off the top of my head there's no reason why we can't just say
>> > in AS2.0 that we can look at the @language in @context but if there's no
>> > @context, just look at a "language" tag. That's typically how I've seen
>> > it in the wild and a lot more intuitive than @context and @language for
>> > non-JSON-LD parsers (i.e. the majority of parsers).
>> IMO all software supporting AS2.0 MUST have support for some basic
>> processing of JSON-LD context. Otherwise it will have *no support* for
>> vocabulary terms outside of very limited AS2.0 Vocabulary. For example
>> no support for email addresses, birthdays or basic data about spoken
>> languages in social profiles etc.
>
>
> If you mean "support for basic processing of JSON-LD context" thats anything
> greater than "reading the @language property", then -1000.
>
> If you say "You need to implement this huge JSON-LD algorithm", most
> programmers will rightfully say "screw this" and do something else. If you
> say "You need to go read the JSON-LD spec", then most programmers will say
> "screw this".
>
> Mandating JSON-LD support is the way to oblivion. I thought ActivityStreams
> was supposed to be a *profile* of JSON-LD?
>
> As far as I'm concerned, any document which requires context processing more
> advanced than reading certain fixed properties (e.g. @language) should not
> be considered ActivityStreams. If you want to use full JSON-LD, go right
> ahead - call it application/ld+json. If you want to interoperate with
> ActivityStreams implementations, use "application/activity+json", which
> implies a default context (the ActivityStreams context, which may be a
> "living vocabulary"*) with a fixed, user-friendly normalization.
>
> The goal of JSON-LD, after all, was to let you use linked data tools on
> mostly arbitrary JSON, right? Why can our spec not be in the "nice, mostly
> arbitrary JSON" subset, without any JSON-LD weirdness?
>
> For graph-structured data (like a social graph!), a graph format (RDF/Linked
> Data) is great, but most apps don't need it and most programmers aren't
> familiar with it.
>
> If the group gives up on the "plain JSON" serialization format, you might as
> well just encode everything in Turtle. You'll attract just as many users and
> avoid all the what-JSON-format bikeshedding.
>
>     Owen
>
> * Expanding the default context may cause some interoperability issues
> between old and new versions of the spec (e.g. a canoncal URI changing from
> http://foo/bar#baz to CURIE bar:baz), but in reality they should be small
> and can probably be worked around in a reasonably easy manner

Received on Friday, 23 October 2015 21:01:33 UTC