Re: internationalization issues

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