RE: Datatyping, rdf:type inappropriate

> -----Original Message-----
> From: ext Jan Grant [mailto:Jan.Grant@bristol.ac.uk]
> Sent: 01 September, 2002 12:41
> To: RDFCore Working Group
> Subject: Datatyping, rdf:type inappropriate
> 
> 
> 
> Currently rdf:type is used to add triples to a graph. The existence of
> the triple in the graph
> 
> 	A <rdf:type> C .
> 
> is used to indicate that A is a member of class C.
> 
> The proposed datatyping document's use of rdf:type does something
> different; it is a syntactic mechanism for encoding a locally-typed
> literal in the extended RDF/XML syntax.
> 
> Dave Beckett pointed out some practical problems with this.

I didn't see any problems in the examples he presented. In fact,
I considered the behavior of the parser in those cases to be
entirely correct.

> In the telecon, Patrick S. said, "it doesn't matter if you used
> foo:blarg for this attribute - a parser would still have to handle it
> [therefore, why not just have a parser handle rdf:type]".
> 
> The issue I'm concerned about is not that a parser writer has to deal
> with this. It's that a user of RDF/XML has to deal with this. 

That's also my concern.

> You've
> taken an attribute that maps onto the label on an arc in a graph and
> turned it into a syntactic mechanism. *That*'s what I mean by
> "overloading".

No. The attribute asserts the rdf:type semantics for the object node.
In the case of URIref resources, it does so with an rdf:type arc. In
the case of typed literals, it does so with a typed literal node. In
both cases, the semantics are *identical*, so too then should be the
means of expressing that semantics in RDF/XML -- even if the representation
in the graph is not identical in both cases.

I'm concerned that, if we introduce another new attribute, we force
users to keep track of two completely synonymous attributes, one for
typed literals and one for typed URIref denoted resources, rather than
just keeping it simple for the users and use the same attribute that
does the very same thing for both.

> If it wasn't for the fact that "parseType" has already been overloaded
> by the DAML collection stuff, _that_ might have been a better 
> choice. As
> it is, I think a new, purely syntactic attribute is by far the
> preferable choice.

If the rdf:type of the resultant typed literal node were not
the datatype, then I would agree that the proposed use would
be purely syntactic.

However, given the semantics of the typed literal node, there
is an implicit triple which is not expressable (at present) in
RDF which is identitical to the typed URIref resource example.

Namely:

   <age rdf:type="&xsd;integer">10</age>

implies

   "10" rdf:type xsd:integer .

as well as

   xsd:integer"10" rdf:type xsd:integer .

Thus, the only reason why that rdf:type arc is not present in
the graph is due to a limitation of the graph syntax precluding
literals as subjects. 

Thus, the use of rdf:type for typed literals is not purely
syntactic, but very much a semantic mechanism that results
in capturing the specified rdf:type semantics by means
of a typed literal node -- rather than an rdf:type arc.

--

I would like to make two requests here:

1. That some other WG members provide their input/opinions
   about this, particularly those working with semi- to
   non-technical users.

2. That those who think rdf:type should not be used, try
   suggesting a better alternative (other than xsi:type).

Thanks,

Patrick

Received on Monday, 2 September 2002 06:06:33 UTC