Re: internationalization issues

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.

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