- From: Pat Hayes <phayes@ihmc.us>
- Date: Sat, 24 Nov 2018 12:40:40 -0600
- To: Hugh Glaser <hugh@glasers.org>
- Cc: David Booth <david@dbooth.org>, Semantic Web <semantic-web@w3.org>
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 exceptions. > (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 https://www.slideshare.net/PatHayes/ikl-presentation-for-ontolog 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 <phayes@ihmc.us> wrote: >> >> On 11/22/18 9:30 AM, Dan Brickley wrote:> This did crop up in json-ld, see >>> https://github.com/w3c/json-ld-syntax/issues/37 with the notion >>> of "generalized rdf" introduced in the last round of specs. >>> https://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf >>> >>> >>> >>> >>> On Thu, 22 Nov 2018, 06:20 Martynas Jusevičius >>> <martynas@atomgraph.com <mailto:martynas@atomgraph.com> 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 >> >>> <martige@ifi.uio.no <mailto:martige@ifi.uio.no>> 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 >> www.ihmc.us/groups/phayes/ >> www.facebook.com/the.pat.hayes >> >> >> > -- ----------------------------------- call or text to 850 291 0667 www.ihmc.us/groups/phayes/ www.facebook.com/the.pat.hayes
Received on Saturday, 24 November 2018 18:41:10 UTC