Re: Semantic Web Interest Group now closed

Ok. And yes, knowledge graphs is a decent term too.

Anthony

On Thu, Oct 18, 2018 at 11:15 PM Dan Brickley <danbri@danbri.org> wrote:

> So we've had sentient web, hyper data, data web, and a bunch of other
> suggestions, on top of our historical attempts at calling "it" the Semantic
> Web, Linked Data, LOD, PICS, PICS-NG etc., plus recently "knowledge graph"
> gaining rapid traction.
>
> May I gently suggest that the name isn't the core problem here? Except
> perhaps that we keep trying to respin things via renaming.
>
> There are serious frustrations that come with trying to use RDF (and
> RDFS/OWL/SPARQL, JSON-LD, RDFa, Turtle, N-Triples et al.), and lack of
> evocative names is rarely top of the list. Part of our cultural problem
> here has often been a kind of defensiveness that comes from our approaches
> often being eclipsed by more mainstream technologies. And with that
> defensiveness sometimes a sense of "if only we could get the messaging /
> pitch / tutorial right, the unbelievers would come to see the beauty and
> simplicity of our approach".
>
> For a long time, RDF's annoyingness was somewhat conflated with it's
> syntax. The initial RDF/XML syntax was put together in discussions which
> focussed more on the underlying graph data model.
>
> We called it a "striped" syntax because XML elements alternately stood for
> nodes vs edges of the underlying graph (
> https://www.w3.org/2001/10/stripes/). TimBL's forgotten Notation 2 was an
> attempt at a unstriped, edge-centric syntax. We've had near countless
> efforts. GRDDL was a well motivated attempt to make a system for mapping
> arbitrary XML into our graph; it seems to have completely failed. The much
> more successful JSON-LD is in some ways a similarly motivated attempt to do
> something rather similar with JSON, via its expressive @context mechanism.
> Recently I've come to suspect that there is something in this direction
> which mixes in schema/validation considerations, so that we can map more
> gracefully to (e.g. binary) JSON, relational and other data models such as
> Protocol Buffers.  So ShEx and SHACL (or vice-versa) and increasingly
> important, as they bridge the wishy-washy "anyone can say anything about
> anything" representational model of RDF with the perfectly human desire to
> have things specified a bit more tightly at the application level.
>
> I love the way the RDF Validation book puts it, in terms of "defensive
> programming". From http://book.validatingrdf.com -
>
> "Veteran users of RDF and SPARQL have confronted the problem of composing
> or consuming data with some expectations about the structure of that data.
> They may have described that structure in a schema or ontology, or in some
> human-readable documentation, or maybe expected users to learn the
> structure by example. Ultimately, users of that application need to
> understand the graph structure that the application expects."
>
> "While it can be trivial to synchronize data production and consumption
> within a single application, consuming foreign data frequently involves a
> lot of defensive programming, usually in the form of SPARQL queries that
> search out data in different structures. Given lots of potential
> representations of that data, it is difficult to be confident that we have
> addressed all of the intended ways our application may encounter its
> information."
>
> This characterization I think is much closer to the truth than our
> historical tendency to blame ugly or unintuitive syntaxes. RDF graphs are
> annoying to build things with because you never know what's in them,
> generally speaking. Edd Wilder-James (aka Dumbill) once likened coding with
> RDF as something like coding without any data structures beyond a
> hashtable. There's truth in that too.
>
> If there is to be value in having continued SW/RDF groups around here,
> it's much more likely to be around practical collaboration to make RDF less
> annoying to work with, rather than high level spinning of it in terms of
> different metaphors and slogans and exhortations for how people should be
> doing it to be doing it "right". We have collectively slipped too easily
> into the latter, and maybe we're doing it again this week. There is enough
> around RDF to be tempting, evocative, to draw people in, to get them
> interested. But people repeatedly hit a wall, and often wander away,
> frustrated. Another reason to nudge our focus towards the likes of SHACL
> and ShEx is that they are technologies that potentially can be used to
> characterize specific application information needs where applications are
> using some-but-not-all RDF data. As a community (especially the scientific
> / scholarly side), Semantic Web has tended towards prizing generality above
> all else. But there is merit too in knowing about applications whose scope
> is much more pedestrian. It is more than fine for an application to consume
> just a few patterns, from the infinite gallery of possible, conceivable,
> RDF graph patterns. And yet as a community we have tended implicitly to
> look down upon these as missing out on the ultra-general-purpose nature of
> our technology. If we are not careful, RDF is something of a spork; a
> highly versatile tool potentially useful for many tasks, and yet neglected
> in favour of the less general (the spoons and forks whose capabilities it
> gracefully generalizes and unifies...). All the renamings and rebrandings
> in the world won't save us from the tragi-niche fate of the spork, but some
> collaboration around the user and developer experience, and explorations of
> how syntactic issues (JSON, Protobufs, XML) relate to RDF validation
> mechanisms could imho make a big difference to the appeal of our
> technologies...
>
> Dan
>
>
>