Re: Proposal to drop S from consideration (new PL option?)

Jeremy Carroll wrote:
> There are currently available general purpose RDF environments with some
> type support that do things differently from S.

Well, in a way, yes; the examples you give seem to take
a perl-esque view of the world; rather than having
distinct string and integer datatypes, there's just
a general-purpose scalar datatype; you can
string-compare (eq in perl) scalars or numeric-compare scalars
(== in perl). In this view, the tenth integer
isn't distinguishable from the two character string "10".

Note that the value spaces of the primitive datatypes
(decimal, string, ...) in XML schema datatypes are
explicitly disjoint, so these views conflict.
(I don't know why the XML schema spec constrains
them to be disjoint; as far as I know, it doesn't
exploit that constraint in any way).

I suggest we use 'PL' to refer to this way of
handling datatypes.

I think I could live with it, but we'll have
to get this conflict with the XML Schema datatype
system reviewed by some peer groups.

> I do not believe that there are any which do things remotely similarly to S.

They all do S out of the box. S only has string literals; they all
support string literals.

> DanC:
> >
> > Do you have some RDF software that treats the value of
> > that property as a date?
> >
> Jena has API support for integers and floating point values in terms of
> regarding the integer or floating point as the interesting value and the
> string just as a lexicalisation.
> See in particular:
> .html#addProperty(com.hp.hpl.mesa.rdf.jena.model.Property,%20long)
> and
> .html#hasProperty(com.hp.hpl.mesa.rdf.jena.model.Property,%20double)

Interesting; what comes out if you do addProperty(shoeSize, 10)
and serialize it? is it different from addProperty(shoeSize, "10")?

Conversely, if I write
and ask whether it hasProperty(shoeSize, 10), do I get a yes or a no

> > Applications on top of RDF parsers that know about dc:date
> > take the string and do date stuff with it. But not
> > the RDF parser itself.
> I don't think we should make a distinction between the parser and the rest
> of the RDF processing.

Ok, point taken; unless I can make a distinction observable
with a test case, it's hardly worth talking about.

I'll see if I can make my point with test cases.

I'm trying to make a point about the requirement
(at least: I think it's a requirement) that RDF
documents be syntactically self-evident; i.e.
that the RDF spec says how to treat an RDF
document as a formula; i.e. something with
exactly one denotation per interpretation
for each node and arc.

> A valid implementation of a type mechanism might
> include an untyped treatment during parsing and applying type rules later.
> Stuff which requires application specific treatment and can't go into a
> general platform is all that is application specific.
> Giving the lack of type support in RDF M&S all a general purpose platform
> can do is give support for the application programmer who has to know which
> values get converted and which don't.
> Query languages such as
> (which is supported in Jena) currently take a very liberal view to typing.
> If it fits the lexical space of an integer, and the query treats it as an
> integer then it is an integer for now.

yes, that's the PL approach. To put it another way: it
operates on integer numerals, not integer numbers.
Or: it doesn't distinguish between numerals and numbers.

Note that such languages don't have any way to
say "I just want integers; don't give me the strings
that happen to look like integers."

> Both Jena and Swish take the view that Patrick is championing that the
> string is just the lexical form, and there is some other value that is not a
> string trying to get out.

I don't think so.

> Concerning Jena, I believe the HP developers will make the effort to support
> whatever this WG recommends. My point is that S will probably require more
> work than some of the other proposals.

I doubt that.

Dan Connolly, W3C

Received on Thursday, 29 November 2001 17:54:56 UTC