Re: ✅ Literals as subjects Re: Toward easier RDF: a proposal

Someone may need to explain to me exactly which problem this would solve, especially in the context of making RDF more approachable.

{ “May” a Month . } isn’t a useful statement/graph to me, because this is mutually exclusive with { “May” a foaf:Person . }.

The only place I can imagine his being useful is statements about the serialization of the string itself, e.g. { “May” length 3; rot13 “Znl” .  }. However, if I should be able to make statements like this about strings, why not any data type? Why not an entire RDF graph, like { { <foo> a <bar> . } published “2014-02-28T00:00:00Z”^^xsd:dateTIme .  } ?

More specifically, someone has to explain why every property should be able to have an inverse. E.g. why do we need separate { ?v hasAuthor ?u } and { ?u authorOf ?v } properties, when we can just say { ?u author ?v } or { ?v ^author ?u . } instead?

This seems to me like it would have totally the opposite effect of making RDF more approachable. I think of RDF as a generalized form of hyperlink, where documents/resources can also link to data, not merely other documents. Making statements about non-opaque data, instead of opaque resources, doesn’t really fit my mental model.

Thanks,

Austin Wright.


> On Nov 24, 2018, at 01:40, Pat Hayes <phayes@ihmc.us> wrote:
> 
> On 11/22/18 6:59 AM, Tim Berners-Lee wrote:>
> >
> >> On 2018-11 -21, at 22:40, David Booth <david@dbooth.org <mailto:david@dbooth.org>
> >> <mailto:david@dbooth.org <mailto:david@dbooth.org>>> wrote:
> >>
> >> 7. Literals as subjects.  RDF should allow "anyone to say
> >> anything about anything", but RDF does not currently allow
> >> literals as subjects!  (One work-around is to use -- you guessed
> >> it -- a blank node, which in turn is asserted to be owl:sameAs
> >> the literal.)  This deficiency may seem unimportant relative
> >> to other RDF difficulties, but it is a peculiar anomaly that
> >> may have greater impact than we realize.  Imagine an *average*
> >> developer, new to RDF, who unknowingly violates this rule and
> >> is puzzled when it doesn't work.  Negative experiences like
> >> that drive people away.  Even more insidiously, imagine this
> >> developer tries to CONSTRUCT triples using a SPARQL query,
> >> and some of those triples happen to have literals in the
> >> subject position.  Per the SPARQL standard, those triples will
> >> be silently eliminated from the results,[13] which could lead
> >> to silently producing wrong answers from the application --
> >> the worst of all possible bugs.
> >>
> >
> > Agreed.
> >
> > I thought we had fixed that in some later spec but I guess not.
> 
> I tried (hard) to get it fixed in RDF1.1, but it was repeatedly ruled out because our charter, delivered on tablets of stone by W3C, did not allow us to make such changes.
> 
> >
> > All code I have written, like cwm and rdflib.js, allows the same
> > things in subject and object positions.  Life is too short for
> > arbitrary unnecessary asymmetry.
> 
> Indeed. But also, not allowing literal subjects means that RDF reasoning cannot be complete, because there are valid derivations whose antecedents and (valid) conclusions are both in valid RDF syntax, but must use triples in generalized syntax. Putting semantically meaningless restrictions on a logical syntax is bad logical design as well.
> 
> Pat Hayes
> 
> >
> > timbl
> >
> -- 
> -----------------------------------
> call or text to 850 291 0667 <tel:850%20291%200667>
> www.ihmc.us/groups/phayes/ <http://www.ihmc.us/groups/phayes/>
> www.facebook.com/the.pat.hayes <http://www.facebook.com/the.pat.hayes>