Re: internationalization issues

Elf,
I think we're saying the same thing here.

Having a field like bitcoin is exactly the same as an implementor not
defining a context for their extension or including it in the name.  I don't
know where you got the idea I am against extensions and I still don't
understand why vendor prefixing concerns you so much then.
Its equivalent to foaf:age with not having a context.  Its just a
change of ':' to '-',
which i'm curious if implementors have had trouble with ':' int the
same way as '@'.

Just using 'age' would be equivalent to aliasing age to foaf:age.  The
difference
is that JSON-LD contexts allows people to validly put in age, and assume
that it is unambiguous, which is a problem for those who will ignore
the context,
which as others have stated, is likely a pretty high percentage.  Its better to
say that all extensions SHOULD be in the form of foaf:age.  Not doing so tells
the publisher of the content that your stream is unambiguous when it is likely
to not be interpreted as such.


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

Yes, it would be ideal to have a location for a living language.



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

This is all optional, especially when context is ignored.  So its actually
already an extension just with an undeclared context minus vendor
prefixing of mf:


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

what?

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

I never said that.

> If someone believes in foo-* 'prefixes' approach which dosn't map to
> URIs, than please propose it for consideration of this group!

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

Received on Saturday, 24 October 2015 12:20:53 UTC