Consider using Turtle for editing gist

[uscholdm]

Turtle designers met their goal of making a much friendlier syntax than rdf/xml. I often make changes in the raw files, and rdf/xml slows me down quite a lot. Can we conver to using Turtle instead, and then include both in releases?

Related to Issue #129

[JonathonGist]

As a newcomer to ontologies and the Semantic web and semantic disciplines, with a few decades of database design, development and data tier architecture, I have found Turtle easy, intuitive and wonderfully concise. I far prefer Turtle to rdf/xml. I would find it much easier to work with gist in Turtle natively, than continue with rdf/xml. My two cents.

[rjyounes]

Do we need to include both in the release package? Can we just make ttl our official serialization and let users convert to RDF/XML or another serialization they prefer? Even if both are included in the package, the URIs have to point to one of them when a request header is not explicitly included.

[JonathonGist]

From my perspective, having only ttl as the official serialization is fine. I like that idea; users who need RDF/XML can convert it. My two cents.

[Jamie-SA]

There may be some issues with returning a ttl file when the URL has no file extension as many parsers use the file extension to determine the file type. It wouldn't surprise me if many pieces of software will assume that a Ontology without an extension is RDF/XML.

[uscholdm]

I think we should include any/all formats that people are likelyi to want. I disagree with the suggestion that it is easy to go into/out of Protege. It a big fiddle, especially if you want to look at the text files.

[JonathonGist]

Protoge isn't an easy tool to learn, from my perspective as a newbie to the semantic technology stack. I love the idea of the easy-to-access ttl being available. But I see there are complicating factors to providing both. I'm not equipped to provide much useful feedback on this topic.

[rjyounes]

@uscholdm What comment about Protégé are you referring to?

[uscholdm]

@rjyounes Somewhere, (maybe in a separate chat on Teams) someone said not to bother with multiple formats because it is easy enough to import into Protege and export whatever format you like.

[rjyounes]

I see. Better to just run rdf-toolkit.jar.

[uscholdm]

For someone who wants to have a look at ontology files and is not a developer, having all the formats available is the answer.

[Jamie-SA]

I agree that it is not hard for us to provide a few different formats and it might make it more convenient for existing and potential users.

[uscholdm]

This has digressed away from the main question of what format we author in. I'd like to move to Turtle.

[rjyounes]

@uscholdm You are suggesting we distinguish the issue of authoring in turtle from the publishing serialization(s)? The bundler will be affected if we edit in Turtle but publish in a different format(s), so @sa-bpelakh should weigh in on that. Let's leave it for a meeting discussion. I can push it up on the list.

[rjyounes]

Everyone wants to edit in Turtle.

[Jamie-SA]

The document referenced by @marksem here confirms what I expected. Admittedly, it is a bit old but is still probably appropriate...

Without proper content negotiation (our current configuration) then returning RDF/XML from our server for the Ontology URIs is the only supported "recipe" (best practice). So the switch to editing in Turtle needs to be combined with a solution for this problem before a release is made.

Two obvious solutions... The simple solution is to provide the standard files in RDF/XML and provide Turtle as an extra file, just generate the RDF/XML from the official Turtle content. The better solution would be to properly support content negotiation (issue #318).