Re: internationalization issues

On 24 October 2015 at 14:31, James M Snell <jasnell@gmail.com> wrote:

> The context serves the purpose of making extensions unambiguous. But,
> there's a reason that use of the application/activity+json media type
> allows the @context to be implied when it's not present... You're
> absolutely correct that many developers will simply ignore it and will be
> perfectly fine doing so.
>
Is there actually any evidence that developers will be in willful violation
of the @context field in this way?  Most developers, even the most basic
web developers operate using cut and paste (there is ample evidence for
this).  So why are we creating a spec based on the assumption that people
will ignore certain parts, and guessing which parts they will ignore, then
adjusting the spec because of this.  This design assumption sounds like the
road to hell.


> On Oct 24, 2015 5:20 AM, "Ben" <ben@thatmustbe.me> wrote:
> [snip]
>
> >
> > okay, but we effectively already have that, its called ignore the
> context.
> > My issue is this, why are we requiring context at all?  Most developers
> > ignore it, at which point it doesn't serve any purpose other than to make
> > it JSON-LD compliant.  So why is, drop JSON-LD and change @ to something
> > that developers will not have a problem with, not a viable option, its
> easy
> > enough to convert TO JSON-LD after that.  I'd be willing to bet if you
> > start coming
> > away from JSON-LD, you can 1p
> > sr
> >
> >
> >
> >
> > On Sat, Oct 24, 2015 at 5:22 AM, elf Pavlik
> > <perpetual-tripper@wwelves.org> wrote:
> > > On 10/24/2015 02:47 AM, Ben wrote:
> > >> map and bitcoin should probably be prefixed, but then there is
> > >> nothing stopping anyone from producing whatever fields they like.
> > >> That's true in any serialization.
> > > We don't want to limit people's personal freedoms, everyone can even
> > > start building their autonomous internet or an alternative to world
> wide
> > > web. I see our common aim as to produce *recommendation* for how to
> > > build systems that interoperate. If someone doesn't care about that, I
> > > believe more exciting literature exist than technical specifications
> > > which we work on here. So for people who don't care about interop, I
> > > would suggest to simply don't pay attention to our work here.
> > >
> > > As James points out in other replies, implementers *MAY* not map
> > > property names to URIs, but they *SHOULD*. Why? To maximize
> > > interoperability and provide high quality (unambiguous) data.
> > > I will think of an example of such potential naming collision, better
> > > than 'bitcoin', which we could add to the spec to inform people about
> > > possible consequence of ignoring that *SHOULD*. This way everyone can
> > > choose but by making informed choice and not basing that choice on FUD.
> > >
> > >
> > >>
> > >> I know, and I find such 'prefixing' practice a concern. When people
> > >> start defining their edu-* collab-* orga-* 'prefixes' we very likely
> may
> > >> end with collisions and no way to tell if same 'JSON keys' and some
> > >> values (eg. types) have same meaning or not.
> > >>
> > >> Isn't this why specs put it lines about avoiding using too many
> extensions
> > >> or there may be problems with interoperability?  Also, if we don't
> fully process
> > >> context, it would be even worse.  prefixing significantly reduces
> > >> chances of collisions
> > >> as opposed to (what i see as likely for most, and almost definite for
> > >> me) ignoring context.
> > > JSON-LD provides clear way to use any number of independent
> vocabularies
> > > (aka extensions) without any interop problems. Of course using multiple
> > > extensions suggests that system requires more complex modeling of
> > > certain domains. Also some vocabularies may have poor alignment and not
> > > aim at modularity and fitting as part of broader environment. But
> still,
> > > those who want to put effort into doing working in such way, have well
> > > designed technology for that purpose.
> > >
> > > I would find it attractive to further align AS2.0 and Microformats.
> > > Where microformats.org could merge with activitystrea.ms and provide
> > > alternative to what schema.org does - a unified living vocabulary for
> > > people who don't feel like working with multiple autonomous
> vocabularies
> > > - a one stop shop for web schemas.
> > >
> > >
> > >>
> > >>
> > >> James, I realized that wasn't very clear, I'm trying to write a
> > >> service to generate AS2
> > >> for any given url of MF2.  While you cannot override the base AS2
> > >> context, it was more
> > >> about generating correct context for any other data I find, just like
> > >> elf found on werd.io
> > >> I've never seen them, but they could be useful, I want to include
> > >> extensions from MF2
> > >> as extensions in AS2, but I cannot.
> > > Unless we explore possibility which I mention above - merging
> > > microformats.org and activitystrea.ms into one unified living vocab.
> > > Microformats vocab SHOULD act as *extension* to AS2.0. Which requires
> > >
> > > 1) official URI prefix for all the terms e.g.
> http://microformats.org/ns/
> > > (IANA link relations will soon also have such official prefix!
> > > https://github.com/mnot/I-D/issues/140)
> > > 2) declaring this prefix in JSON-LD context eg. "mf":
> > > "http://microformats.org/ns/"
> > > 3) using CURIEs mf:like-of
> > >
> > > This requires a single line in JSON-LD context and than prefixing terms
> > > with mf: and than using some kind of helper method which based on
> > > prefixes in JSON-LD context will compare CURIEs in their expanded,
> > > globally unique form.
> > >
> > > As of now I see state of things between AS2.0 and Microformats as kind
> > > of a dead lock
> > > 1) we don't want to get along and agree on unified living vocabulary
> > > with open governance. BTW schema.org has regular steering group
> meetings
> > >
> https://github.com/schemaorg/schemaorg/labels/For%20Steering%20Group%20Attention
> > > 2) we are right and their are wrong, and in the end we will win this
> > > struggle!
> > >
> > > At the same time, your data and statements suggests that you already
> > > today can't rely exclusively on Microformats vocabulary and *already
> use
> > > vendor prefixes*. In this case I consider all the arguments of "we
> don't
> > > need extensibility" as simply proven wrong! At the same time, if
> someone
> > > doesn't appreciate mechanism proposed in AS2.0 spec, this person
> > > *SHOULD* propose changes to it, or *SHOULD* propose alternative
> > > mechanism. Worst thing we can do - pretend that we don't need to face
> > > this issue (which your website proves we do) and make ourselves and
> > > others believe that everything will work just fine if we just ignore it
> > > in our recommendations. If someone believes in foo-* 'prefixes'
> approach
> > > which dosn't map to URIs, than please propose it for consideration of
> > > this group!
> > >
> > > Cheers!
> > >
> > >>
> > >> On Fri, Oct 23, 2015 at 5:53 PM, elf Pavlik
> > >> <perpetual-tripper@wwelves.org> wrote:
> > >>> On 10/23/2015 11:22 PM, Ben wrote:
> > >>>> Offhand I cannot thing of a quick link.  Most of my prefixes are in
> > >>>> data I send from my posting app to my site, i know i use this for
> > >>>> posting drafts to my site.
> > >>> Could you at some point still share with us some of you custom
> > >>> properties and possibly types?
> > >>>
> > >>> I noticed on http://werd.io/ use of properties
> > >>>
> > >>> * bitcoin (on h-card)
> > >>> * map (on h-entry)
> > >>>
> > >>> Which I don't find on
> > >>>
> > >>> * http://microformats.org/wiki/h-card
> > >>> * http://microformats.org/wiki/h-entry
> > >>>
> > >>> In bitcoin example, some people could use just the hash as value,
> some
> > >>> people URI as bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W
> > >>> https://en.bitcoin.it/wiki/BIP_0021
> > >>>
> > >>> Who specifies how to use 'bitcoin' property, or 'map'?
> > >>>
> > >>>
> > >>>>
> > >>>> Aaron uses his own p3k prefixes on http://aaronparecki.com/metrics
> > >>> I know, and I find such 'prefixing' practice a concern. When people
> > >>> start defining their edu-* collab-* orga-* 'prefixes' we very likely
> may
> > >>> end with collisions and no way to tell if same 'JSON keys' and some
> > >>> values (eg. types) have same meaning or not.
> > >>>
> > >>> If we drop URI based extensibility, I would like to hear clear
> proposal
> > >>> for alternative strategy.
> > >>>
> > >>> Cheers!
> > >>>
> > >>>>
> > >>>> On Fri, Oct 23, 2015 at 5:10 PM, elf Pavlik
> > >>>> <perpetual-tripper@wwelves.org> wrote:
> > >>>>> Hi Ben,
> > >>>>>
> > >>>>> On 10/23/2015 11:01 PM, Ben wrote:
> > >>>>>> 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).
> > >>>>>
> > >>>>> How do you propose to handle 'your own vendor prefixes'?
> > >>>>> Could you maybe even provide an concrete examples with ones which
> you
> > >>>>> use in your data?
> > >>>>>
> > >>>>> Thanks!
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> > >
>
>