RE: Datatypes Draft Questions & Comments

> -----Original Message-----
> From: ext Stephen Petschulat/CanWest/IBM [mailto:spetschu@ca.ibm.com]
> Sent: 30 August, 2002 17:00
> To: w3c-rdfcore-wg@w3.org
> Subject: Datatypes Draft Questions & Comments
> 
> 
> 
> ACTION 2002-08-23#4, SteveP - Comments on:
> http://lists.w3.org/Archives/Public/www-archive/2002Aug/0111.html
> 
> Note I'm addressing my comments to the new two part document.
> 
> 1.2 Desiderata...
> 
> I'm not sure bullets 5-7 on global vs. local typing issues 
> need to be in
> the desiderata. They sound confusing and clutter up an 
> otherwise nice list
> of high level goals for RDF Datatyping.

Well, those were desiderada put forth by WG members. If the
final proposed solution does not address them, then we should
say so clearly. But they still remain valid input into the
process.

It certainly would be possible to try to do some wordsmithing
to make them clearer.

> 3.1 Global Datatyping Assertions
> 
> It might be nice for this example to show a triple using the 
> "age" property
> to demonstrate the redundant typing information (w/ a forward 
> link to the
> section discussing this issue). The datatype assertion by itself seems
> incomplete.

Yes. I'll add that.

> 3.2 Datatype Clashes
> 
> Implementors of RDF software will undoubtedly want to know 
> how to deal with
> these issues. E.g. does local typing override global typing? 
> The wording
> "care must be taken" isn't terribly helpful. These clashes 
> will be a common
> occurance. If every piece of RDF software deals with them 
> differently then
> the benefits of having a datatyping standard is diminished.

Well, this is a difficult issue, because as far as I understand,
none of the specs tell applications what to do if there are
contradictions in the RDF knowledge base -- and that is precisely
what a datatype clash is, a contradiction.

I think the best way to address this is to remain agnostic, but
try to make clearer that we are deliberately remaining agnostic
rather than simply forgetting to tell applications what to do.

> 6.1.2 Gobal Datatyping Excludes...
> 
> Is the example provided then invalid RDF or is the user just 
> not allowed to
> make the inference at the MT level?

This is a good point. This section is worded too strongly. Having
an rdfs:range assertion with an inline literal is syntactically
legal -- only the MT does not provide any interpretation for that
combination. An application is not licensed by the MT to infer
that the literal denotes a datatype value, nor is it licensed by
the MT to infer that it does not denote a datatype value. It is
free to choose how it wishes to interpret the inline literal
in terms of the rdfs:range assertion.

I'll try to rework the wording to reflect this more accurately.

> Usage of "tidy/untidy" terms... these terms have the 
> potential to confuse
> an outside audience rather than clarify.

Agreed. That's why in the restructured document, in part 2, I've
tried to use other terms (string semantics vs. value semantics).
I don't know if the new terms are any clearer than the old terms,
but I hope they are.

> Is it *impossible* to come up with a MT that supports both global
> datatyping and inline implicit literals or the *current* MT 
> doesn't support
> both?

The MT in Part 1 remains completely silent about the meaning of
inline literals. It is not possible to decide the semantics of
inline literals (tidy vs. untidy) without also impacting (essentially
deciding) global implicit datatyping. Choosing to make inline
literals tidy (self-denoting) precludes global implicit datatyping
of inline literals. Choosing to make inline literals untidy (value
denoting) allows the regular semantics of rdfs:range to work (i.e.
you get global implicit datatyping automatically).

Though, Pat may have some comments about this, which may help
clarify things better than I have been able to thus far.

Regards,

Patrick

Received on Sunday, 1 September 2002 02:02:18 UTC