Re: internationalization issues

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

Received on Saturday, 24 October 2015 09:22:25 UTC