- From: bergi <bergi@axolotlfarm.org>
- Date: Fri, 3 Jul 2020 23:49:40 +0200
- To: Dan Brickley <danbri@danbri.org>, Aidan Hogan <aidhog@gmail.com>, David Booth <david@dbooth.org>, Pat Hayes <phayes@ihmc.us>
- Cc: semantic-web@w3.org
> [clipped] > > > (terminological aside) When folk here talk of getting rid of bnodes, is > this an (unfortunate) shorthand for getting rid of non-URI bnode labels > from rdf-related syntaxes? > > > > > We have - scattered across the Web - mountains of Schema.org written > mostly in json-ld and Microdata, published on tens of millions of sites, > describing in varying levels of detail, umpteen-bazzilion real world > things. Most of that has bnodes for non-literal nodes in the graph. > Those nodes have types like Event, Person, Place, Product, NewsArticle, > ClaimReview etc. Having been part of the effort to get RDF into the > lives of ordinary people since 1997 I consider this a win. > > In our experience with this effort at Google, the usability issues come > into play more when you try to hook up these mini-graphs across > documents, sites or parts of pages. This is the case regardless of > whether the graph-connectivity is achieved via URIs or via other tricks. > It is just more complicated for most people, compared to the standalone > case with no external dependencies to consider. > > Telling publishers they have to manage and assign URIs to every node in > the graph would - if successful - certainly make life easier for data > consumers. But it would be a massive up front usability hit to the > entire effort. I believe it would simply fail in the primary Schema.org > scenarios in mainstream web markup. > > I am afraid btw that talking in terms of "middle 33%" of developers sets > us a monolithic and rather elitist perspective on how skills and > abilities with modern networked computing can be compared. Someone might > be amazing at CSS, site speed optimization, analytics, accessibility and > in understanding the needs of a site's various user constituencies, > without happening to conceptualize Schema markup in graph database or > open data aggregation terms. What % of the way up the developer rankings > are they? who cares! What's a "developer" anyway? > > > While I would be very happy for more parties to publish and consume > Schema.org "as graph data", and to appreciate the power that comes with > data linking, layering merging via well known identifiers,... you just > can't force this on people by changing some w3c standards. Wikidata > provides a more inspiring example, where people are seduced into taking > the [knowledge] graph perspective because it is powerful and useful. Not > because w3c banned something from a spec. > > Banishing URI-less IDs from graph formats is a recipe for more junk IDs > polluting the data and jumbling up the graph connectivity. It is > important to leave our data formats open enough for publishers to be > able to mention some real world entity in passing without jumping > through bureaucratic hoops. > > We live in an age when I can sit in a cafe and program via Python a > pretrained neural network (using my phone!) to classify the species of > bird depicted in a photo I have just taken (it was some kind of coot, I > think). Just a few years ago, this was rocket science - > https://xkcd.com/1425/ is between 5 and 10 years out of date. In such a > historical moment do we truly wish to be the group who tell the world > that they are not allowed to write data that say things like "... in the > country whose name is France" instead of "in the country > https://dbpedia.org/resource/France"? Even those who don't laugh at us > will ignore our demands (and file formats). More carrots and less > sticks, please. "Killing bnodes" is shifting work from data consumers to > data publishers, in an environment when we want publishers to publish > more data not less. +1 I didn't follow the whole discussion, because I don't see the need to have a discussion with the topic "Blank nodes must DIE" and I guess I'm not the only one, but many others are tired of having the discussion. I'm using RDF with blank nodes for years and didn't have big problems. When I had a closer look at the problems people had with blank nodes, I always noticed it's actually a problem with their tooling. So get your tooling fixed, get maybe some higher-level specs fixed, but the RDF model doesn't need a fix at that regard. bergi
Received on Friday, 3 July 2020 21:50:00 UTC