Re: Toward easier RDF: a proposal

On Sun, Nov 25, 2018 at 8:30 PM Paul Tyson <phtyson@sbcglobal.net> wrote:

> On Thu, 2018-11-22 at 00:51 +0000, Nathan Rixham wrote:
> > Remove everything you can from the full set of specs, until you can
> > implement a working version of the full stack in roughly a week, and
> > you'll have something 100% of us can use.
>
> But which would perhaps only cover 20% of what we need. They are big not
> because of bloat, but because they are precise and complete with respect
> to their domain of application.
>

I'd suggest it would be nearer ~80%, but won't argue the point.


> In the past I developed 2 nontrivial production applications, each of
> which used a
> different set of components from the RDF technology stack. All told:
> RDF, RDFS, OWL, SKOS, SPARQL, RDB2RDF, and RIF. I learned these, as
> needed, by reading the specs. I relied heavily on the XML technology
> stack, especially xslt, to stitch everything together, as well as SQL to
> get at the legacy data sources.


I have a similar background, though avoided the XML/XSLT route, RIF I have
not been lucky enough to utilize commercially as yet. Personally I fell
comfortable with 40-80% of the specifications, there are some nuances and
heavy bits in each that take me out of my comfort zone, and some which lead
me to asking the authors on lists.

Now my day job has me maintaining and extending a large web-based
> document delivery application. It uses a popular javascript MVC
> framework and some HTML templating languages.


I'm interested to know, do you use any of the RDF related stack in your day
job? (excluding the common data in html cases we could file under
structured data for seo, perhaps even excluding publishing rdf/ld).

In my own day job, we don't use any of the stack being discussed (outside
of publishing ld that is), and that's my own call as I'm the tech lead. I
want to, and it's fast approaching the time where we need to, I just can't
warrant the usage of any of it yet, as it's not commercially viable.


> But here's the big difference between learning a framework and learning a
> standard: When
> you learn a standard, you profit from many person-years of expert
> experience, consideration, debate, analysis, and review. When you learn
> a framework, you learn what seemed like a good idea at the time to a few
> developers working on a particular problem set within some limited
> context. To be sure, there are magnificent frameworks and libraries
> built on solid principles, but none has had or will have the staying
> power of the XML or RDF technology stacks.
>

Agree in principal, but then you also have to contend with rigidly sticking
to past mistakes, political rather than technical decisions, things that
were deemed out of scope - the standardization process is not without flaw,
and doesn't always produce the best nor most practical result.

We probably have very different viewpoints, and very similar problem
domains / day jobs. I think I could categorize my own viewpoints as being:

(a) I need the RDF stack to be something more like N3, standardized by
people working on very scalable systems with very light footprints. Closer
to NoSQL-JSON-JS than SQL-XML-Java.
(b) I feel like the RDF stack, is what happens when you take N3, cut it
down, and try to do it in XML with old enterprise systems, then build it
back out out for a decade or two whilst trying to maintain bc.

.. and there it is, thank you Paul for helping to frame this in a way where
it's clear to me. (a) is what I need, and can help to do. (b) currently
exists and is in use. I can wade back out of this discussion, as it's
possible to proactively do something about (a), then use it.