W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > April 2002

RE: motivation for bNodes/existentials in RDF; note for parsers

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 3 Apr 2002 12:15:14 -0600
Message-Id: <p0510150fb8d0f26339e3@[65.217.30.94]>
To: "Massimo Marchiori" <massimo@w3.org>
Cc: "Dan Connolly" <connolly@w3.org>, "Pat Hayes" <phayes@ai.uwf.edu>, "w3c-rdfcore-wg" <w3c-rdfcore-wg@w3.org>, "Lynn AndreaStein" <las@olin.edu>, "Jan Grant" <Jan.Grant@bristol.ac.uk>
>  > > So, summing up, since this is a fundamental architectural decision
>>  > (not just syntactic sugaring) concerning RDF, what is most interesting
>>  > is to give the reasons for this interpretation vs the easiest
>>  skolem one.
>>  > Yes, it's a classic "last call" fundamental question, because
>>  that spawns
>>  > into the data model, on which there are many things to discuss,
>>  but well,
>>  > Dan brought the matter up early ;)
>>
>>  At the first WG F2F we had a long (and, i think, productive) argument*
>>  about this. Sergei produced a good set of pros and cons; my arguments
>>  for this are ...
>>
>>  - supports "non-assertional" mode, ie, RDF querying by turning around
>>    the "X entails what?" into "what entails X?"
>>
>>  - aesthetic reasons, and those of transparency. When I write an
>>    assertion with a blank node, I intend it to mean "there exists...".
>>
>>  - DanC also claimed that skolemisation was too much of a general
>>    impediment to getting software written :-) I think he may have
>>    been dramatising for, well, dramatic effect, but I've some sympathy
>>    with this POV. In other words, supporting anonymous nodes requires
>>    some API fiddling, but is not necessarily a "simpler mechanism".
>
>Thanks for the initial reply, Jan.
>I don't want to start a complex debate without first having seen a complete
>reply, just noticing that this is such a fundamental architectural decision
>that a complete and careful pro/con analysis is due. The above three "pro"
>reasons
>all have good counterarguments,

I'd be interested in hearing them.

>so I'll wait to see for the full official
>motivation-and-reasoning behind such a milestone decision.
>
>-M

For me, the fundamental motivation for not skolemizing blank nodes 
concerns entailment. Consider an RDF graph G1 and another graph G2 
got from G1 by erasing some of the node labels, ie replacing urirefs 
with blank nodes. Does G1 entail G2? Seems to me that the answer has 
to be 'yes' in order to capture the intended meaning of blank nodes 
as described in the M&S. If blank nodes are hidden skolemizations, 
however, the answer is 'no'. So skolemized graphs do not adequately 
support the proper RDF entailment conditions.

It would be fine for blank nodes to have some kind of 
implementation-dependent hidden labels - in effect, that is what the 
bnode labels in Ntriples are - but the critical point is that these 
labels are not treated like urirefs; they have no global scope, and 
are not meaningful outside the graph, and are not treated 
semantically as names.

RDF could be redefined without blank nodes, of course, but it would 
be a different, and much weaker, language. In effect, it would be a 
simple positive propositional logic, with no quantification. 
Skolemized nodes are not blank, so the whole concept of anonymous 
nodes would be eliminated from the language, rendering it simpler in 
both its syntax and its semantics. I agree that this is a fundamental 
architectural decision, but it seems to me that the M&S has already 
clearly made the decision: the language does contain blank nodes. 
Given that decision, skolemization is not an option. The milestone 
decision was taken long ago, and all we are doing is stating it more 
precisely.

Pat Hayes
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Wednesday, 3 April 2002 13:15:15 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:47:20 EDT