- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 25 Sep 2002 11:59:19 +0300
- To: "ext Jeremy Carroll" <jjc@hpl.hp.com>, <w3c-rdfcore-wg@w3.org>
[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com] ----- Original Message ----- From: "ext Jeremy Carroll" <jjc@hpl.hp.com> To: <w3c-rdfcore-wg@w3.org> Sent: 25 September, 2002 10:27 Subject: Re: On Consensus > > ... > > Before we have taken on board the things from the schema, there appears to be > nobody in the group who would assert that the bitsPerPixel = "8" is equal to > the age <xsd:int>"8" . > > It is difficult to justify why the bitsPerPixel "8" should (without the schema > information) be viewed as unequal from the eg:name "8". True, but we could also have ccpp:bitsPerPixel _:x"8" and eg:name _:y"8" and I don't expect that anyone in the group would assert that they definitely are equal (though they could be). > After we have read the schema, even the one with the comment and no range > constraint; it seems that an RDF application would be justified in storing > the bitsPerPixel as an int, and finding that it was equal to the eg:age and > different from the bitsPerPixel. We would not expect *any* application to read comments. Having an explicit range assertion is another matter entirely. And yes, if explicit range assertions are present in the graph, then an application may conclude equality, given identical datatype and lexical forms. > If we buy this end-to-end argument from the original document through to the > final application level semantics we see that one equality is true initially > and false at the end, the other if false initially and true at the end. This > is the essence of non-monotonicity and somewhere we *must* have made a > non-monotonic step. There is no such non-monotonicity in the untidy treatment if we have uniquely labelled inline literals with systemID prefixes, as the MT would not permit any such systemID prefixed literals to be deemed equal unless the datatyping knowledge is explicitely defined in the graph, and even then only if they have the same datatype and identitical lexical form; otherwise, equality can only be tested by extra-RDF applications with full knowledge of the datatype(s) in question. But it is fully monotonic. The key is having the systemID prefix. > 3: untidy semantics - RDF contains a non-monotonicity > ... > > 4: syntactic transform - tidy semantic > ... > [Some people, such as Patrick, appear to argue for position [3] with as a > condensed form of 4 - hmm, I seem to see Patrick as arguing for both 3 and 4 > - there are faults with my analysis]. I think, yes, I am arguing for a combination of 3 and 4, and just as the typed literal node can be seen as a compression of the triples _:x rdf:type ddd . _:x rdf:value "LLL" . into ddd"LLL" I am viewing inline literals as being a compression of the triple _:x rdf:value "LLL" . into _:x"LLL" But I see this as being fully monotonic, including across all application layers, such as those employing value-based semantics. > This transform has the distinct disadvantage of changing the RDF graph related > with almost all RDF documents .... The above "hybrid approach" of 3+4 would not change the graph in this way. > SUMMARY > > There is a nasty bump. We can push it one way or another way but it doesn't go > away. It is essentially an engineering decision about where the bump will > cause the least accidents. But again, accidents to whom? And when? I think we each need to clarify for ourselves whether we are thinking most about our present software and what this decision means for us over the next few months versus future semantic web software and what this decision will mean for RDF users for years to come. Patrick
Received on Wednesday, 25 September 2002 04:59:21 UTC