Re: Please publish Turtle or JSON-LD instead of RDF/XML [was Re: Recommendation for transformation of RDF/XML to JSON-LD in a web browser?]

The discussion in the other thread has shown that RDF/XML conversion to
JSON-LD or Turtle is easy in many popular languages.  Often I have to
export stuff as RDF/XML for use by older tools and I have not hit the
corner cases in the export,  although I sure have hit corner cases inside
the tools and with good 'old N-Triples.

I agree with the theme that pedagogy is important,  RDF beginners or
part-timers need to see how simple it really is and the newer formats help
with that.

There is though a change in psychology that comes with JSON-LD which boils
down to the role of ordered collections in RDF.

Despite all it lacks,  JSON is broadly popular and I think that is because
it is based on the $-scalar, @-list and %-hash model that was in Perl,
 that most dynamic languages since then put those on your fingertips and
they are in the standard library even in those awkward languages.

There is a fear of ordered collection in RDF because it brings up a number
of issues with blank nodes,  but when it comes down to it you can express
what people are trying to express in JSON in Turtle and it doesn't look all
that different.

JSON-LD transparently adds what is missing in JSON,  such as decimal types
which are correct for handling money as well as the ISO 8401 'standard' for
dates and times which is better than no standard at all.

It is so much fun to work with a RDF graph the same way you would with a
JSON document,  then do some rules-based inference,  do a SPARQL query or
add the graph to a big graph with millions of other documents and query
*that* with SPARQL.

The connection with XML is something to be revisited too.  Kurt Cagle told
me that he got into RDF because he saw it is as the logical continuation of
XML.  That's really right,  since RDF incorporates the types from
XML-schema.

What we need is a way to throw XML into a meat grinder,  decompose it into
triples without any configuration at all.  I will say I had GRDDL,  XSLT
and all they stand for and much prefer to just build out an XML DOM graph,
 which won't be quite the graph you want but with SPARQL CONSTRUCT queries,
 production rules, and a few specialized operators it is easy and much more
structurally stable than XSLT.



On Thu, Sep 3, 2015 at 3:04 PM, Sarven Capadisli <info@csarven.ca> wrote:

> On 2015-09-03 19:03, David Booth wrote:
>
>> I encourage all RDF publishers to use one of the other standard RDF
>> formats such as Turtle or JSON-LD.  All commonly used RDF tools now
>> support Turtle, and many or most already support JSON-LD.
>>
>
> I have grown to (or to be brutally honest; tried very hard to) remain
> agnostic about the RDF formats. This is simply because given sufficient
> context, it is trivial to point out which format is preferable for both
> publication and expected consumption.
>
> The decision to pick one or more formats over the other can easily boil
> down to understanding how and what will be handling the formats in the
> whole data pipeline.
>
> It is great to see newcomers learn N-Triples/Turtle, because it is as
> human-friendly as it gets (at this time) to read and write statements. That
> experience is also an excellent investment towards SPARQL. Having said
> that, we are not yet at a state to publish semantically meaningful HTML
> documents by authoring Turtle. There is the expectation that some other out
> of band code or application needs to wrap it all up.
>
> By the same token, JSON-LD is excellent for building applications by
> imperative means, however, it is stuck in a world where it is dependent on
> languages to manipulate and make use of the data. To generate it, it
> depends on something else as well. <Insert argument on JSON-LD being a tree
> structure just like RDF/XML here. GOTO 10>.
>
> At the end of the day, however the data is pulled or pushed, it needs to
> end up on some user-interface. That UI is arguably and predominantly an
> HTML document out there. Hence my argument is that, all roads lead to HTML.
>
> As I see it, RDFa gets the most mileage above all other formats for prose
> content, and a fair amount of re-use. It ends up on a webpage that is
> intended for humans, meanwhile remaining machine-friendly. A single code
> base (which is mostly declarative), a single GET, a single URL
> representation to achieve all of that.
>
> I still remain agnostic on this matter, because there is no one size fits
> all. After all, in the command-line, N-Triples still has the last word.
>
> So, as long as one speaks the RDF language, the rest tends to be something
> that the machines should be doing on behalf of humans any way, and that
> ought to remain as the primary focus. That is, speak RDF, keep improving
> the UI for it.
>
> All formats bound to age - with the exception of HTML of course, because
> it still rocks and has yet to fail! ;)
>
> -Sarven
> http://csarven.ca/#i
>
>


-- 
Paul Houle

*Applying Schemas for Natural Language Processing, Distributed Systems,
Classification and Text Mining and Data Lakes*

(607) 539 6254    paul.houle on Skype   ontology2@gmail.com

:BaseKB -- Query Freebase Data With SPARQL
http://basekb.com/gold/

Legal Entity Identifier Lookup
https://legalentityidentifier.info/lei/lookup/
<http://legalentityidentifier.info/lei/lookup/>

Join our Data Lakes group on LinkedIn
https://www.linkedin.com/grp/home?gid=8267275