Add assertions for language objects and text direction (issue 598)

[mmccool]

• Be specific about where @language tag can appear to simplify processing (this is an extension of issue noted below...)
• Add assertions to indicate how base text direction is to be inferred from default language outside of MultiLanguage contexts, including requirement for script subtags if necessary (btw, an example of the latter is az-Latn vs az-Arab)
• Make LTR the default text direction if no default language is given
• Script subtag required in MultiLanguage. I also moved the assertions regarding language tags from ontology/td.ttl to validation/td-validation.ttl to be consistent with other such assertions, and marked them up with rfc2119-assertion spans.

Addresses Issue #598

[mkovatsc]

I made a few comments for possible improvements. Otherwise looks good! We might want to discuss if this is rather a serialization issue...

[mmccool]

I agree there are a lot of issues that are serialization related. On the other hand I think being specific about things like where the @language tag can appear in the @context will make things more consistent and easier to parse. But your point about it making this difficult when a JSON-LD library is used to output a TD is valid so I can remove these.

I'll see if I can find a good place to move the (remaining) serialization constraints that are more logical. I can update the PR tomorrow... I have to anyway to resolve the conflicts now.

[mkovatsc]

+1 to define the allowed location of @language and its meaning of default language in the model (Section 5).

The serialization-specific issues including the i18n aspect should go into Section 6. There I would rename the titles and descriptions section to "Human-readable Metadata Serialization" and put it there.

[mmccool]

I'm not convinced these text direction issues are serialization issues. Text direction affects how the text is displayed, but does not affect how the bytes are ordered in storage or when communicated (which is what "serialization" means). Given that, do you still feel I should move the points I left open above to Section 6?
By the way, this also resolves the issue with "support". We can treat "support" as "potentially human-readable" text and apply text direction of the default language to it if it is rendered on a display device. But if it is a URI this does not matter: you will just process the bytes in the order they appear in memory.

[mmccool]

I took a look at section 6 and noticed some new assertions had been added at some point that were redundant with the ones I had added under MultiLanguage, eg the use of language tags and inference of text direction. However, I still assert that these are NOT serialization issues since the text direction does not affect how the data is stored, it affects how it is interpreted, so it's legitimately part of the information model. However, redundancy is bad, so I removed the extra assertions (actually, they were tacked onto the end of another assertion and not given their own id, which was another problem...). I did rename the section to "Human-Readable Metadata" and added a note about the fact the @language definition can be serialized in its own object or combined with others.

[mmccool]

But HTTP language negotiation is arguably part of serialization, so I did move that assertion to section 6.

[mmccool]

Also moved assertion for "independent processing" to Section 6.

[mmccool]

I think all the issues raised in the review have been addressed, and IMO this is ready to merge.

All issues have been addressed (I think).

[mmccool]

I created an additional PR to add a definition for "supportLanguage":mmccool#8. This is a modification of this PR.

[mkovatsc]

Good work. Final polishing changes...

[mkovatsc]

@mmccool can you make sure that the default language also applies to the name? See comment in #630...

[mmccool]

The intention is that the default language also applies to "name". It also applies to "support". The text includes the following (in "Human-Readable Metadata"):

When a default language is specified by assigning a value to @language in the @context of a Thing object, that default language is associated with the string values assigned to title and description within the TD and to name and support in the Thing object.

[mmccool]

I think all the review issues have now been addressed. Please take a look.

Note I have not yet updated the supportLanguage sub-PR. I will do that soon, I have to fix some conflicts...

[mkovatsc]

Arg, GitHub eats up the HTML tags I wrote in the comments.. thus confusion in places where I wanted you to add the markup such as anchoring to the definition...

[mkovatsc]

We have a few comments on skipping on the supportLanguage feature.

The name must be defined to underlie the default language. The other way round, the name given must be in the default language (i.e., no English name when comments are in Arabic).

Let's fix support and think some more about name...

Support must be independent of default language (to become an anyURI).

[mmccool]

+1 for making support an anyURI. Probably we should create another issue for it, although I could certainly add that change to this PR.

The default-language-changing-upon-negotiation problem still exists for "name" but if I make a few small changes to my sub-PR (eg changing "supportLanguage" to "nameLanguage") it would be one possible solution. Note in the issue I created I made a list of other possible solutions. One simple approach would be just to ignore the default language for "name" and use a strong-first rule to determine the text direction. That is a little fragile (and is "not recommended" in the i18n guidelines) but would be simple.

My preference though would be to define "nameLanguage" and in (an update to...) my sub-PR.

[mkovatsc]

See #630 comment. It does not make sense to introduce names and nameLanguage when we have titles already.

[mkovatsc]

We should merge this soon, as it has lots over good and important changes!
Can you fix

title and description within the TD
and to name and support in the Thing object

to only title and description? Then we should be good unless there are other places that indicate name.

[mkovatsc]

@mmccool Have you actively edited any of the ontology files or is it just render noise?

[mmccool]

My edits were in index.template.html, validation/td-validation.ttl, and ontology/td.ttl. Unfortunately there is some content hidden away in the ontology files that needed to be updated. Everything else is render noise (specifically all of ontology/.html and visualization/.svg).

[mmccool]

The last open issue in the reviews was about support. I marked it as "resolved" but the true resolution will be to make it an anyURI.

I think this is ready to be merged now.

[mmccool]

I will let you do the merge when you are ready.

[mkovatsc]

Waiting for @sebastiankb as I am not officially an Editor of this draft...

[mmccool]

Ah... well, I am an editor. Let me go ahead and merge, then.