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

Re: On Consensus

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 25 Sep 2002 11:59:19 +0300
Message-ID: <004d01c26471$d565dd20$d74416ac@NOE.Nokia.com>
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 EDT

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