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

Hi David,

My perspective as an iOS developer is that it might be useful to explain
blank nodes in terms of value types and reference types (blank nodes being
value types), as that's the terminology we're already familiar with.

Then you could say something like:

IDs starting with  _:  identify value types, all other IDs identify
> reference types.


Then you could compare primitive and composite value types and what to use
in RDF, giving typical examples:

    Primitive value types - Use RDF literals:
        e.g. String, Int, Double, Boolean.
    Composite value types - Use RDF blank nodes:
        e.g. Address, Coordinate, Fraction.

Then instructions on comparing instances of value and reference types, as
that's the main difference:

   - Value types: Compare by comparing various properties, the method will
   vary by type.
   - Reference types: Compare by comparing identifiers.

So maybe rather than getting rid of blank nodes they just need to be
explained in terms of what developers already know. In Swift for example we
have Structs and Classes (value types and reference types, respectively),
and the use of Structs is actually encouraged in most situations—see the
links below. JSON-LD comes somewhat close to this terminology actually, it
uses "node object" and "value object".

Regards
Anthony

*[Swift] Structures and Classes*
https://docs.swift.org/swift-book/LanguageGuide/ClassesAndStructures.html

*[Swift] Value and Reference Types*
https://developer.apple.com/swift/blog/?id=10


On Tue, Jun 30, 2020 at 5:52 PM Jiří Procházka <ojirio@gmail.com> wrote:

> 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
> >
>
>