Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

I don't consider that as radical of a proposal as many do. People value
different RDF(S)/OWL/RIF/N3 features differently, as their use cases
differ.

I think a lot of real RDF usage in the wild doesn't care much about any
RDF logic, inference, entailments and treat RDF as an upgraded data
language, most value provided by IRI/URI identifiers, shared
vocabularies and graph structure. They are authoring their data,
ingesting, cleaning and filtering external data, merging it and
processing in based on their own algorithms/logics.
This group would be mostly fine with some "RDFCore" without blank nodes
and maybe other stuff. Just graphs and triples.

On the other hand people who care about logic and entailments usually
care about it a lot and what RDF(S) provides is not a lot. If you want
more, it gets really complex. I agree that even the RDF specifications
are not approachable for a common programmer. On the other hand what
seems approachable and simple is N3, and it can even do more than RDFS!
RDFS constructs can be defined using N3 rules, blank nodes can be
replaced by explicit N3 existential variables over entire graph.
As any rule language seems simple to me than OWL/RDFS, RIF could be an
alternative to N3. I can read rules fine, they can be accompanied by
helping descriptions, but with OWL/RDFS we have just the descriptions
and formal semantics which (both) have been misunderstood by many.

So how about specifying a simple clean RDFCore and rule based logic on
top of that? How is that for a radical proposal?

J.

PS: For the RDF -> RDFCore cleanup there have been numerous ideas, but
off top of my head what has resonated with me is:
1) No blank nodes.
2) Include named graphs/surfaces, vocabulary for relations between them
and triples, to overshadow RDF reification.
3) Vocabulary for semantic extensions, if their terms break any
features, like monotonicity.
4) Subject and object should allow the same node types, property
possibly too.
5) Remove and have a recommended descriptive vocabulary (no special
semantics) for highly reusable stuff like: collections, containers,
6) Recommendation and vocabulary for representing n-ary relations.
7) Good support for binary data literals.
8) Simple resource equality rules (IRI/URI rules are complex).
9) Vocabulary for dereferencing / Linked Data. rdf:seeAlso.
10) Consider merging literals into resources for example using something
like ValueProperty (subclass of rdf:Property, range: literals). Data URI
scheme? Replace literal language tags and literal datatypes by a
descriptive vocabulary.

On 7/1/20 12:32 AM, David Booth wrote:
> On 6/30/20 3:12 PM, Patrick J Hayes wrote:
>>> On Jun 30, 2020, at 9:40 AM, David Booth wrote:
>>> I REALLY wish that some PhD students would take on this
>>> challenge: to design a higher-level successor to RDF,
>>> with a top-line goal of making it easy enough for AVERAGE
>>> developers (middle 33% of skill), who are new to it, to be
>>> consistently success.
>>
>> Might that be (a subset of?) OWL2 using the Manchester syntax?
> 
> I doubt it, even though the Manchester syntax does make OWL much more
> understandable than OWL-in-Turtle.  Two reasons:
> 
>  - I think OWL itself is too hard for average developers (mid 33%).
> Although the various OWL constructs in isolation -- expressed in
> Manchester syntax, at least -- are understandable enough, average
> developers (the onese I've seen) don't exhibit the precise careful
> reasoning of a logician.  And they don't approach applications as a
> logician would, by starting with a few iron-clad axioms and rules that
> they've thought long and hard about, adding data, and then turning a big
> reasoner crank to get the desired results.  They approach applications
> more operationally, through a series of small steps that they can
> successively implement and test, to eventually produce the desired
> result at the end.
> 
>  - The majority of RDF (or graph database) applications that I see are
> much more like big data integration problems than semantic inference
> problems, and they typically do not need OWL.
> 
> There certainly are some projects that make important beneficial use of
> OWL -- based on the OBO Foundry ontologies, for example -- but from what
> I've seen, they're not generally done by *average* developers.  There's
> usually a PhD or two involved.
> 
> Anyway, that's what I've seen.  Others might have different views.
> 
> David Booth
>