Consider Internationalization patterns in JSON-LD?

hybox / models

Data Modeling repository for HyBox (ontologies, vocabularies, best practices, requirements, etc)

Apache License 2.0

5 stars 3 forks source link

Consider Internationalization patterns in JSON-LD? #14

Closed azaroth42 closed 8 years ago

azaroth42 commented 8 years ago

Consulted: @mjgiarlo @no-reply @cbeer

There are three internationalization patterns in JSON-LD, which result in the same underlying triples (langString + tag) however have different requirements for developers and the context layer.

Q1: Is this decision in modeling's scope, or engineering? My thought is modeling, but it could also be shared, or just an engineering question. Q2: Assuming that it's at least partly on us... Each pattern has its pros and cons, and the determination of which is best likely falls on the anticipated interactions. See: https://www.w3.org/TR/json-ld/#string-internationalization

But feedback on Q1 first?

mjgiarlo commented 8 years ago

Given that we have working models in Sufia now that don't require JSON-LD, suffice to say I think this can be in modeling's scope (since we may not use the JSON-LD at all in implementing the model).

no-reply commented 8 years ago

I think it's an engineering question, with advice (and possible implementation assistance--I'm not sure what serialization flags we have for this sort of thing in RDF.rb's JSON::LD) from modeling.

It seems mainly to have to do with serialization; though the line between modeling/engineering on @context is fuzzy for me, too.

azaroth42 commented 8 years ago

@mjgiarlo Working -internationalization- models?

Which brings up ... is i18n actually a requirement? I'm perhaps too used to a11y and i18n being a fundamental requirement.

mjgiarlo commented 8 years ago

Ah, no, I missed that. We just use what Rails provides for i18n but it'd be good for the model to suggest how we should be serializing i18nized data from the app. Thanks for steering me in the right direction, @azaroth42

azaroth42 commented 8 years ago

Consider examples in: https://github.com/IIIF/iiif.io/issues/755 :)

azaroth42 commented 8 years ago

I'd like to propose:

i18n of the application is in the scope of engineering (e.g. button labels, tooltips, etc) and can be done however you want
i18n of the data is in the scope of modeling (e.g. of title, description, notes, etc) and should use rdf:langString and tags, with the JSON-LD language map construct as the expected serialization [Given the clarification from @gkellogg that a simple string or array of strings is acceptable]

Thoughts?

mjgiarlo commented 8 years ago

:rocket:

no-reply commented 8 years ago

I think we can safely say that i18n of the data is in scope for modeling, and largely resolved by reference to RDF 1.1 Concepts Sec. 3.3.

I was initially less concerned by the specifics of the serialization, but upon thinking about it further, I'm in favor of specifying JSON-LD w/ language map construct as a required serialization. This is good info to get to the tech team, since we've already identified (and fixed) some pretty serious performance edge cases for Ruby JSON-LD since the 2.0.0 beta release.

azaroth42 commented 8 years ago

Okay, closing the issue -- i18n of data is in scope, covered by RDF1.1, and we'll recommend the language map pattern for JSON-LD. :shipit: