W3C home > Mailing lists > Public > www-rdf-comments@w3.org > April to June 2004

RE: On rdf:parseType non-qualified values. DAML+OIL annotation on the same subject.

From: Manuel Vázquez Acosta <manu@chasqui.cu>
Date: Mon, 28 Jun 2004 11:28:29 -0400
To: "'Jeremy Carroll'" <jjc@hplb.hpl.hp.com>
Cc: <www-rdf-comments@w3.org>
Message-Id: <20040628152838.D138AA17F5@frink.w3.org>

Thanks for your response. Currently I have no other comments on the subject;
so you may close my comment.

Regards,
Manuel.


Lic. Manuel Vázquez Acosta
Grupo Chasqui®
UCLV.

 
-----Original Message-----
From: Jeremy Carroll [mailto:jjc@hplb.hpl.hp.com] 
Sent: Wednesday, June 23, 2004 4:43 AM
To: Manuel Vázquez Acosta
Cc: www-rdf-interest@w3.org
Subject: Re: On rdf:parseType non-qualified values. DAML+OIL annotation on
the same subject.


The RDF Core WG did consider whether parseType could be a true extension 
point, but couldn't get it to work. Hence, we effectively deprecated the 
suggestions in RDF Model & Syntax that this was an extension point, and 
migrated the "daml:collection" parse type (which was the only use of the 
extension point that we were aware of) into the main syntax, as 
parseType="Collection".

Technically the problem is that how does a conformant parser know what 
to do with an unknown parseType. This production:

http://www.w3.org/TR/rdf-syntax-grammar/#parseTypeOtherPropertyElt

was what we ended up with, treating any private extended use of this as 
parseType="Literal"

The recently publish Quality Assurance Specification Guidelines WD has 
some relevant comment:
http://www.w3.org/TR/2004/WD-qaframe-spec-20040602/#extensions

particularly
[[
Prevent extensions from breaking conformance

Extensions must not contradict or negate conformance to the 
specification. If it conformed without the extension, conformance should 
hold true with the extension.
]]
our experience was that daml:collection did not fit with such a 
principle, this led to dropping parseType as an extensibility point.

Once we had decided that it was not an extensibility point then the 
argument to permit URIs or qnames as the parseType is moot.

I note that you made this as a formal comment; unfortunately the WG has 
now closed, meaning that you are unlikely to get a formal reply any time 
soon. I guess it would be helpful that if you find this informal reply 
adequately addresses your comment, that you say so, and we could mark 
the comment as closed.

Jeremy




Manuel Vázquez Acosta wrote:

> Hi all:
> 
> I'm wondering why just rdf:parseType values are not require to be a
resource
> identified by its URI.
> I think it'd be better to have something like:
> 
> <ex:Stuff rdf:parseType="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag">
> 	<rdf:li rdf:resource="http://www.example.com/items#1"/>
> 	<rdf:li rdf:resource=" http://www.example.com/items#2"/>
> </ex:Stuff>
> 
> Then DAML+OIL "daml:collection" parseType (written as %daml;collection)
> would be fully qualified in the DAML+OIL namespace instead. As it is now,
is
> just a 'reserved' string for the parses to take account of it. 
> 
> Moreover, DAML+OIL parses must recognize this string to have a special
> meaning, and I think the whole point of RDF is NOT to give any special
> meaning but to resource (I know rdf:parseType is just a RDF/XML shortcut,
> and therefore not part of the RDF semantics). But I still think
constraining
> rdf:parseType to be resources would lead to a more extendable language;
not
> to mention that other RDF-flavored languages could be created to describe
> such a new parseType.
> 
> Regards,
> Manuel.
> 
> Lic. Manuel Vázquez Acosta.
> Grupo Chasqui®
> UCLV.
> 
> 
Received on Monday, 28 June 2004 11:28:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:33 GMT