Re: Denotation of datatype values

On 2002-04-12 15:37, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
wrote:

> Patrick,
> 
> I'm pleased that my comments don't include any surprises for you.  I'm
> vaguely concerned about some of the things you go on to say about nodes
> "denoting", but rather than respond here I'll focus my energies on the
> forthcoming document (rather than have you write everything twice ;-).

Fair enough.

Note that I've just uploaded the revisions that I've been working
on today (in parallel with email between you and Jos ;-) and that
sections 2-3, 5-7 I consider to be pretty much ready for serious
review. I doubt that anyone in the WG needs the introduction in
section 1 and the relation of RDF Datatyping to RDF Schema
covered in section 4 is not as core to the discussion as the
rest, and may also be impacted on any agreed changes to the
completed sections. If you think section 4 is critical to your
review, I plan to have it done by late Monday/ early Tuesday.

Note: I've opted in this revision for rdfd:datatype rather than
rdfd:range as the latter seems to be causing folks indigestion and I
must admit that when taking the view that it is the datatype semantics
which impose the constraints on the idioms (by providing valid
interpretations of them), all rdfd:datatype is doing
is associating a datatype context with a property, and thus
is not really itself defining any kind of range.

I've also updated the illustrations for the levels of interpretation
and completed all the illustrations for the above mentioned "completed"
sections.

Feel free to have a gander at what's there now
(http://www-nrc.nokia.com/sw/rdf-datatyping.html) and
tell me if the language better reflects the unique nature
of rdfd:datatype.

Cheers,

Patrick

PS: In case anyone is concerned about keeping track if intermediate
versions, I'm zipping and archiving regular snapshots to www-archive
under the subject "YYYY-MM-DD-rdf-datatyping.zip".


> 
> At 02:07 PM 4/12/02 +0300, Patrick Stickler wrote:
>> On 2002-04-12 13:33, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
>> wrote:
>> 
>>> Er, do we have a disconnect here?
>>> 
>>> Pat, if you're following this:  I note your document that was at
>>> <http://www.coginst.uwf.edu/users/phayes/simpledatatype23-02-2002.html> is
>>> no longer there.  Has it been moved?  It would be good if it were kept
>>> available for a while, since that seems to be our last published point of
>>> consensus.
>>> 
>>> Anyway, to resume normal programming...
>>> 
>>> At 09:53 AM 4/12/02 +0300, Patrick Stickler wrote:
>>>> On 2002-04-11 18:53, "ext Graham Klyne" <Graham.Klyne@MIMEsweeper.com>
>>>> wrote:
>>>> 
>>>>> At 12:22 PM 4/11/02 +0200, Jeremy Carroll wrote:
>>>>>> Now we add the range constraint on <age>
>>>>>> 
>>>>>> <Jane> <age> "25" .
>>>>>> <film> <title> "25" .
>>>>>> <title> <range> <xsd:string> .
>>>>>> <age> <range> <xsd:integer> .
>>>>>> 
>>>>>> We now have the film's title delivered as <xsd:string,"25"> the
>>>> woman's age
>>>>>> delivered as <xsd:integer,"25"> and they are different.
>>>>>> Hence we see defeasible reasoning: in the light of new information we
>>>> revise
>>>>>> our knowledge that Jane's age is <xsd:string,"25">, which in turn
>>>> causes us
>>>>>> to revise our conclusion that Jane's age and the film's title are the
>>>> same.
>>>>> 
>>>>> My understanding of PatH's last proposal is that this graph is not
>>>>> satisfiable.  More precisely:
>>>>> 
>>>>> [[[
>>>>> <Jane> <age> "25" .
>>>>> <age> <range> <xsd:integer> .
>>>>> ]]]
>>>>> 
>>>>> is not satisfiable because "25" denotes a string and <xsd:integer>
>> does not
>>>>> contain strings in its class extension.
>>>> 
>>>> This is true if <range> equates to rdfs:range. I presumed it
>>>> equated to rdfd:range, in which case, there is no problem.
>>>> 
>>>> It really will help, Jeremy, if you use the precise vocabulary
>>>> that we have come up with, especially if commenting on the current
>>>> WD, otherwise, we have no basis for mutual understanding. I know
>>>> that to some extent, you are trying not to beg the question by
>>>> keeping some terms somewhat ambiguous, but it makes it too hard
>>>> to know exactly what you mean. If you mean rdfs:range, please say so.
>>>> If you mean rdfd:range, again, just say so. etc. OK?
>>> 
>>> Ummm... if you mean to interpret <range> as <rdfd:range>, then according to
>>> something Pat said a while ago [1], that has _no effect at all_ on the
>>> denotation of anything.  That simply describes a syntactic constraint on
>>> literal labels in the RDF graph (which are satisfied by the above examples
>>> so can be dropped without having any any further effect on the semantics).
>>> 
>>> #g
>>> --
>>> 
>>> [1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Mar/0241.html :
>>> 
>>> [[
>>> Right. The point is that rdfs:drange (or whatever we call it) really
>>> says nothing about the actual range: it ONLY invokes datatype
>>> checking. Now, one might reasonably expect that the actual range was
>>> 'in line' with the datatype checking, but that could be
>>> ]]
>> 
>> 
>> But this is precisely what I was trying to say. That rdfd:range
>> says nothing about the rdfs:range of the property -- BUT it does
>> provide a datatype context for the interpretation of both the blank
>> node (if present) and the literal node which (if valid) identifies a
>> specific datatype value, and which fixes the denotation of the bnode
>> (if present) to that value.
>> 
>> It may be clearer to say that it is the datatype context that asserts
>> the constraints on the lexical forms and which values the blank nodes
>> denote, and all rdfd:range defines is that context. To that end,
>> perhaps the earlier suggested name rdfd:datatype would be better,
>> since these same constraints and interpretation are asserted by the
>> datatype property as well, or rather, those constraints and
>> interpretation are only asserted by the datatype, and the only real
>> function of rdfd:range is associate the datatype with the property
>> to provide datatype context for the property values. (?)
>> 
>> Insofar as what the bnode denotes, we could view the three levels of
>> interpretation as degrees of datatyping precision:
>> 
>> Level 1: MT (no datatyping)
>> 
>> The bnode dennotes a non-literal resource
>> (we don't even know that it should be a datatype value).
>> 
>> Level 2: Datatyping
>> 
>> The bnode denotes a single specific value identified by a datatyped
>> literal pairing (but we don't know which value it actually is, we
>> only know that there's only one that can be identified by the
>> datatyped literal pairing we have).
>> 
>> Level 3: Extra-RDF/Datatype aware
>> 
>> The bnode denotes a single specific and known datatype value.
>> 
>> 
>> 
>> 
>> Patrick
>> 
>> 
>> --
>> 
>> Patrick Stickler              Phone: +358 50 483 9453
>> Senior Research Scientist     Fax:   +358 7180 35409
>> Nokia Research Center         Email: patrick.stickler@nokia.com
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> 
> 

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Friday, 12 April 2002 09:00:39 UTC