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

RE: Datatyping: new medium-range proposal from HP

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 2 Oct 2002 17:59:25 +0100
To: "Dave Beckett" <dave.beckett@bristol.ac.uk>, "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: "w3c-rdfcore-wg" <w3c-rdfcore-wg@w3.org>

> Is this in the rdf/xml *syntax* or in the semantics?  It would have
> to be the former in order to generate the datatyped literals without
> schema information, which is not presently required for going from
> rdf/xml to ntriples.  After all, inside the programming language, the
> model always includes the type, even if the syntax lets it be elided.

Syntactic - this proposal is entirely syntactic.
Semantically this is the tidy proposal.

> Fine.  Please say more about what rdf:Datatyping is.  Are triple
> generated here?

It is a syntactic construct that, if it appears at all is the first child of
the rdf:RDF element.
No triples are generated (see example).

> OK with me.  By 'new types',  you mean two new rdfs:Datatype

I did, but that is not crucial - it is crucial that there is a type clash
> > Range constraints in a schema are understood as constraints not as long
> > range datatyping. Thus with the previous data
> >
> > foo:prop3 rdfs:range xsd:decimal .
> >
> > simply fails (is contradictory); as would be:
> >
> > foo:prop3 rdfs:range xsd:string .
> I think you'll have to say more about this - how clashes?

If we have

a ex:p1 <xsd:int>"10" .
ex:p1 rdfs:range xsd:string .

then (on all currently live proposals) there is a type clash. We extent this
mechanism to create a type clash between an untyped literal and any
(semantic) schema range constraint.

So in the example

_:a foo:prop3 "10" .

can be read as

_:a foo:prop3 <rdf-untyped-langstring-literal>"10".

And <rdf-untyped-langstring-literal> is not an xsd:decimal, nor is it an
xsd:string; thus there is an error (inconsistency).
This error is exhibited when schema processing.

Received on Wednesday, 2 October 2002 12:56:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:16 UTC