Tabbed layout of TTL?

[HolgerKnublauch]

@TallTed suggests to layout TTL source snippets so that the objects of triples are horizontally aligned where possible.

I think if we do this change, it should be done everywhere, not per individual PR. This will be much easier as the very last step before publishing, because otherwise we risk creating unnecessary work. For example, when a new longer property name is added, everything needs to be pushed right.

[afs]

-1

We have some short property names, including a. A large amount of white space after a is not great.

ex:MyShape
	a                   sh:NodeShape ;
	sh:targetSubjectsOf ex:MyInstance ;

What about SHACL-C?

[TallTed]

A large amount of white space after a is not great.

This certainly looks terrible with two or three rows. It makes more sense, and is clearer, with more rows, whether generated by more predicates or more objects.

We could use rdf:type to decrease this space slightly.

ex:MyShape
    a                   sh:NodeShape ;
    rdf:type            sh:NodeShape ;
    sh:targetSubjectsOf ex:MyInstance ;
.

We could use the somewhat absurd http://www.w3.org/1999/02/22-rdf-syntax-ns#type to increase the whitespace following other predicates.

ex:MyShape
    a                                               sh:NodeShape ;
    rdf:type                                        sh:NodeShape ;
    http://www.w3.org/1999/02/22-rdf-syntax-ns#type sh:NodeShape ;
    sh:targetSubjectsOf                             ex:MyInstance ;
.

We could also right-aign the predicate column, and left-align the object column, to make it clearer which predicate pairs with which object(s). (I generally prefer to do this with more complex examples, but have not applied it in SHACL WG documents yet.)

ex:MyShape
                      a sh:NodeShape ;
               rdf:type sh:NodeShape ;
    sh:targetSubjectsOf ex:MyInstance ;
.

ex:MyShape
                                                  a sh:NodeShape ;
                                           rdf:type sh:NodeShape ;
    http://www.w3.org/1999/02/22-rdf-syntax-ns#type sh:NodeShape ;
                                sh:targetSubjectsOf ex:MyInstance ;
.

(Note that my indents and separators use only space characters, while the preceding example from @afs indented with tabs [on a 4--spaces-wide basis, while the GitHub default is 8-spaces-wide].)

This is one of those things that involves a lot of the taste of the consumer. I wish it were an easy thing to let the reader choose at the top of both the document and each example, as that would obviously let us satisfy everyone.

As things stand, I find including the optional whitespace producing clear columns makes such examples much easier to comprehend for people who are unfamiliar with the immediate subject — even when they're experienced programmers or Turtle workers. This is my primary argument for any of the above, all of which I prefer to the common four-space-indent of all predicates, one-space-separator between each predicate and their first object, and eight-space-indents of second and later objects.

[afs]

indented with tabs [on a 4--spaces-wide basis, while the GitHub default is 8-spaces-wide].)

And in the HTML CSS it's 3.

[HolgerKnublauch]

As I already stated elsewhere I don't support this proposal and would vote -1

[TallTed]

[@HolgerKnublauch] I don't support this proposal and would vote -1

Do you mean that you would formally object to this formatting?
Or just that you don't want to apply it?

As I've said elsewhere and above, I find such formatting benefits the reader, especially but not only when they are unfamiliar with the subject at hand. As anecdotal evidence, an unsolicited testimonial from a reader on StackOverflow (it's the comment from Jay Gray dated Mar 22, 2019 at 7:05.

I would be happy to take on the task of applying this columnization (probably the first example in my earlier comment), if I do not have to wait until the last minute to do so. I would not want to create an excessively large number of PRs, nor many merge conflicts for others, so I would want to start soon, and probably create one PR per top-level section of each relevant document; possibly one PR per second-level section.

---

[@afs] -1

Do you mean that you would formally object to this formatting?
Or just that you don't want to apply it?

We have some short property names, including a. A large amount of white space after a is not great.

Addressed above. I don't feel that the short property a or rdf:type breaks the comprehension boost. Predicate strings vary in length. This is true whether the value strings are columnized or not. I have found that stanzas with indentation more comprehensible by the learning reader, no matter how much the predicate string lengths vary.

What about SHACL-C?

What about it? Can you provide an example that shows your concern about what my columnization might do to SHACL-C (or -CS; abbreviation decision still pending, I think)?

[HolgerKnublauch]

@TallTed I think the spirit of this new WG so far has been positive enough so that no formal objections were ever needed. So in this case my suggestion is: if you (or anyone) really strongly believes this is helpful, they are welcome to submit a PR across all documents before the documents get frozen (next year?) and we can then look again. Until then I think this is unnecessary extra work, messes up the diffs, and doesn't look good in general. Personally, I don't want to further spend time on this topic until that. Busy enough.

[TallTed]

submit a PR across all documents before the documents get frozen

It seems to me that creating such a PR would demand that the documents were frozen to start, then the PR could be created and submitted and evaluated. Else, there would still be the much-feared mass of merge conflicts to handle, and under the significant time pressure of transition requests, publication moratoria, etc.

Further, as I read the reception to date, you're effectively asking me to invest multiple days on a project which would still be resisted and scorned by at least one editor before any group consideration would be given to merging that PR.

Next time you don't "want to further spend time on [a] topic", please resist the temptation to bad-mouth and/or "-1" it, and let the rest of the group speak before you do.