Re: Blank nodes as predicates Re: Blank Nodes Re: Toward easier RDF: a proposal

On 11/22/18 5:28 PM, Hugh Glaser wrote:> Well done, David, great 
initiative, and thanks, Pat, for the clarification.
 > FWIW I hate blank nodes with a passion.
 > But what I hate with even more passion is lack of regularity 
(some would say lack of symmetry), so that I have to remember 
 > (It's the functional programmer in me!)
 > And worse still, especially in the context of this discussion, 
the problem of having to explain the exceptions to other developers.
 > So it is a source of embarrassment to me when I explain the 
beauty of RDF triples to them, and then in the next breath have 
to explain that subjects are not like objects, because you can't 
put literals in them.
 > And even worse, the consequence of that is that you will have 
to choose "hasName" and "hasBirthday" type predicates, as we 
don't support "nameOf" and "birthdayOf" direction.
 > Pat, presumably if I can have literals in subject position, I 
can have them in the predicate position too?

Yes, as far as the semantics is concerned.

 > That would be great (I have no idea what it means, but it 
would still be great not to have to explain another exception :-) )

I have no idea what it would mean, either, but my experiences 
with the (WAY more expressive and complicated) ISO Common Logic 
standardisation and the subsequent IKL logic for interoperation 
deeply agrees with your intuition here. We called it "wild west 
syntax". Basically, if you take away syntactic restrictions 
unless they are absolutely necessary, this will allow expressions 
which SEEM to make no sense, but all of those will quite quickly 
get used in a natural way to mean something useful. For example, 
we thought that allowing quoted names to be properties was crazy 
at first, but we allowed it on the wild west principle, since 
nobody could think of a reason to disallow it; and it turned out 
to be critical for the IKRIS project, allowing us to 'tag' names 
by their source, so we had a natural way to refer to the 
thing-that-this-name-means-in-that-document, and to state rules 
about it, such as that it will be the same thing in all documents 
of a certain category. (see 
slide 15 etseq.)

 > And while we are on introducing simple RDF to people, it would 
be good to have a common visual representation of RDF.
 > Again, I usually go down the route of nodes (subject/object) 
and edges (predicates); but then have to fudge things when people 
ask what happens when predicates are also in subject/object 
positions in the RDF.

Well, THAT is just normal RDF. Happens a lot in the RDFS specs, 
for example.

 > (Sorry if there is something well-known out there).

Pat Hayes

 > I do understand that changing these things might cause 
problems for existing tooling.
 > But having homogeneity actually simplifies a lot of tooling, 
as you don't have to worry about where thing might appear.
 > Now, next question.
 > Where do graphs appear in all this?
 > Can I have blank nodes and literals in the graph position?
 > Clearly my answer would be "yes, please".
 > And what would a simple visual representation look like with 
graphs involved?
 > In fact, graphs seem to have gone remarkably unmentioned in 
this discussion - but they are a source of serious effort for 
dealing with a lot of the stuff that developers need to deal 
with, especially when combining from sources.
 > It's easy to burn serious amounts of time getting the graphs 
and associated granularity right.
 > That's enough from me, I think.
 > Best
 > Hugh
 >> On 22 Nov 2018, at 21:00, Pat Hayes <> wrote:
 >> On 11/22/18 9:30 AM, Dan Brickley wrote:> This did crop up in 
json-ld, see
 >>> with the notion
 >>> of "generalized rdf" introduced in the last round of specs.
 >>> On Thu, 22 Nov 2018, 06:20 Martynas Jusevičius
 >>> < <> wrote:
 >>>      Is that really an essential problem? With blank nodes as
 >>>      predicates,
 >>>      will it suddenly become easier to build RDF 
applications and
 >>>      explain
 >>>      it "for dummies"?
 >>>      A lot of infrastructure will break and/or will have to be
 >>>      updated,
 >>>      that is for sure.
 >> FWIW, allowing bnodes in predicate position (and literals in 
subject position) does not affect the RDF semantics at all. The 
2014 RDF 1.1 semantics specification applies to generalized RDF 
syntax without changing a single word.
 >> Infrastructure which checks for conformance to RDF syntax 
would need to be changed, obviously, but the changes should be 
minimal as they simply amount to not performing certain syntax 
checks which are currently required.
 >> Inference engines which perform any kind of unification 
should generalize to the more liberal syntax with minimal changes 
to code, although indexing and hashing might need more 
substantial changes. But any RDF inference engine which is 
complete will probably be already using generalized RDF syntax, 
or something equivalent, internally.
 >> Basically, it would be a lot easier than many people think.
 >> Pat Hayes
 >>>      < <>> wrote:
 >>>       >
 >>>       > On 22/11/18 13:02, Tim Berners-Lee wrote:
 >>>       > >> On 2018-11 -21, at 22:40, David Booth wrote:
 >>>       >
 >>>       > >> Blank nodes are special second-class citizens
 >>>       > >> in RDF.  They cannot be used as predicates,
 >>>       > >
 >>>       > > Agreed it messes up the symmetry.  Actually in most of
 >>>      my code you can
 >>>       > > use a blank node as a predicate.  That said, RDF is
 >>>      unusual in having as
 >>>       > > much symmetry.
 >>>       >
 >>>       > I like symmetry. Can we get a ✅ for blank nodes as
 >>>      predicates too?
 >> ✅
 >>>       >
 >>>       > Martin
 >>>       >
 >> --
 >> -----------------------------------
 >> call or text to 850 291 0667
call or text to 850 291 0667

Received on Saturday, 24 November 2018 18:41:10 UTC