Our resolution is: xmlsch-01 as in 0252 with amendment. i.e.The RDF Core WG interprets this comment as two questions and a comment:
- 1) Why is the type of a literal not described using a property arc, as is done for other literals?
- 2) Having introduced typed literal nodes, why not introduce typed resource nodes and typed property arcs as well
- 3) The WG should provide a rationale for this design in the specificationsRegarding question 1:This would require that literals be allowed as subjects of RDF statements. This is not possible in current RDF/XML and would require considerable change, beyond the scope of the WG, to support it. Further it introduces problems of non-monotonicity in the semantics. A property whose value is plain literal is currently taken to denote a sequence characters. Adding a further statement could change that value to, say an integer, invalidating previous inferences and breaking a fundamental tenet of RDF.Regarding question 2:No requirement justified a change to the notion of a URIREF node or an RDF arc.Regarding comment 3:Providing a rationale document to accompany the specifications would certainly be nice to have, but the working group chose to spend its writing resource on explanatory text and formal specification rather than justification. We reject this comment on the grounds that the specifications are not intended to provide a rationale.
On question 1: Thank you; that helps clarify the design.On question 2: In the final analysis this is your call and we don't plan to lie down in the road over it. For the record, though, we should record that we find your analysis unconvincing. The introduction of typed literals introduces a new idea into RDF, and it is obvious that this new idea has possible applications elsewhere in the design space. Your response amounts to saying that you chose not to work through the design implications of introducing this kind of type labeling, because it seemed possible to get by without such re-thinking. The result is that the new idea will continue to feel incompletely integrated into RDF; it will feel like a patch added as an afterthought rather than an integral part of the design.On comment 3: We understand your desire not to work your editors to death. Your one-paragraph response to question 1, however, does a good job of clarifying the point that was obscure to us, and we think it may not be beyond the wit of your editors to introduce its substance into the text at some appropriate point.Overall: we are not wholly convinced by your resolution of this issue but do not wish to appeal to the Director on it.
<exterms:age>27</exterms:age> <exterms:age> 27 </exterms:age> <exterms:age> 27 </exterms:age> <exterms:age> 2<!--* ha, ha, fooled your full-text indexer! *-->7 </exterms:age>The input information set, in each case, contains a character information item for “2” followed by a character information item for “7”, with character information items for whitespace characters, and a comment information item, present in some of the examples. In all cases, the lexical form proper is the character sequence “27” (i.e. the sequence of characters after white space handling, and ignoring comments, processing instructions, entity boundaries, and other distractions). This is a legal lexical form for an integer, so all the examples are type valid.
<exterms:age> 27 </exterms:age>and a processor hands the contents of the element to a generic type-checker for XML Schema's simple types, saying in effect “this purports to be the lexical form of an integer; is that OK?”, that type checker will be required (if it conforms to the XML Schema spec's definition of the simple types) to say “no, the character sequence ‘ 27 ’ is not a legal lexical form for an integer.”
The RDF Core WG resolved: xmlsch-02 addressed by msg-0097 where msg-0097 is http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0097.html and saysPROPOSE RDF Core accepts the comment xmlsch-02 and agree to add the following test case:<rdf:Description rdf:about="http://www.example.org/a"> <eg:prop rdf:datatype="&xsd;int">3</eg:prop> </rdf:Description>Does not entail<rdf:Description rdf:about="http://www.example.org/a"> <eg:prop rdf:datatype="&xsd;int"> 3 </eg:prop> </rdf:Description>Moreover the following comment to be added to concepts:NOTE: In [XML Schema (part 1)], white space normalization occurs during validation according to the value of the whiteSpace facet. The lexical-to-value mapping used in RDF datatyping occurs after this, so that the whiteSpace facet has no effect in RDF datatyping.In fact more test cases were desired, and the test cases created are currently awaiting final WG approval and can be found in: http://www.w3.org/2000/10/rdf-tests/rdfcore/xmlsch-02/The Manifest file describes four tests showing that::
- A well-formed typed literal is not related to an ill-formed literal. Even if they only differ by whitespace.
- A simple test for well-formedness of a typed literal.
- An integer with whitespace is ill-formed.The actual text corresponding to the agreed note is found at the end of section 5 http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Datatypes a certain amount of editorial descretion was taken to consolidate notes concerning your comments.The full note from the editors draft is:Note: When the datatype is defined using XML Schema:...+ In [XML-SCHEMA1], white space normalization occurs during validation according to the value of the whiteSpace facet. The lexical-to-value mapping used in RDF datatyping occurs after this, so that the whiteSpace facet has no effect in RDF datatyping.
Thank you for your reply.The XML Schema Working Group is in agreement on one point of our reply and divided in our opinion on a second point.First, we are agreed that the position you sketch out is not a source of logical inconsistency which will render your specification meaningless or logically problematic. It is entirely possible for you to handle whitespace in this way.On the second point, our views are divided.A minority of the Working Group believes that you have made a reasonable design choice, given that RDF will only ever be produced by and consumed by software, and that humans and issues of human legibility are not and should not be matters of concern in your design.A larger portion of the Working Group vigorously disagrees and believes that for RDF processors to treat your two test cases differently is to build into RDF a potential for astonishing users and leading to unexpected results which will haunt you and your users for years to come. In this view, it is not as a matter of compatibility with XML Schema, but as a matter of common-sense concern for your users that you should simply say that the whitespace processing specified for the type in question should be performed by any RDF processor.Overall: we do not have consensus either to express satisfaction with your resolution of this issue or to raise a formal dissent. In the opinion of our chair, this means there is no formal dissent, but he recommends that this point be listed during the review of formal dissents as an issue on which there was not perfect consensus.
A datatype mapping is a set of pairs whose first element belongs to the lexical space of the datatype, and the second element belongs to the value space of the datatype:
- Each member of the value space may be paired with any number (including zero) of members of the lexical space (lexical representations for that value).
We decided:PROPOSED to clarify xmlsch-03 xmlsch-04 pfps-13 based on the proposal to close in http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0368.htmli.e.PROPOSE
- xmlsch-03 - we globally use the term lexical-to-value mapping instead of datatype mapping or any other term
- xmslch-04 - we do not change the definition of value space but add a note clarifying the relationship with XML Schema datatypes.The new text can be found in the editors draft at: http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Datatypes and reads:5. Datatypes (Normative)The datatype abstraction used in RDF is compatible with the abstraction used in XML Schema Part 2: Datatypes [XML-SCHEMA2].A datatype consists of a lexical space, a value space and a lexical-to-value mapping.The lexical space of a datatype is a set of Unicode [UNICODE] strings.The lexical-to-value mapping of a datatype is a set of pairs whose first element belongs to the lexical space of the datatype, and the second element belongs to the value space of the datatype:Each member of the lexical space is paired with (maps to) exactly one member of the value space. Each member of the value space may be paired with any number (including zero) of members of the lexical space (lexical representations for that value).A datatype is identified by one or more URI references.RDF may be used with any datatype definition that conforms to this abstraction, even if not defined in terms of XML Schema.Certain XML Schema built-in datatypes are not suitable for use within RDF. For example, the QName datatype requires a namespace declaration to be in scope during the mapping, and is not recommended for use in RDF. [RDF-SEMANTICS] contains a more detailed discussion of specific XML Schema built-in datatypes.Note: When the datatype is defined using XML Schema:
- All values correspond to some lexical form, either using the lexical-to-value mapping of the datatype or if it is a union datatype with a lexical mapping associated with one of the member datatypes.
- XML Schema facets remain part of the datatype and are used by the XML Schema mechanisms that control the lexical space and the value space; however, RDF does not define a standard mechanism to access these facets.
Thank you; this looks better.
With one exception, the datatypes used in RDF have a lexical space consisting of a set of strings.
RESOLVED: do not accept xmlsch-05Rationale: It feels like a fairly extensive editorial change. Also in the semantic web activity documents xsd:string is always refered to in its qualified form, and so the possible confusion is diminished.
Thank you; we believe you are making a mistake but we will not insist on our suggestion.
- A plain literal is a string combined with an optional language identifier. This should be used for plain text in a natural language. As recommended in the RDF formal semantics [RDF-SEMANTICS], these plain literals are self-denoting.
RESOLVED: to accept xmlsch-06, with revised wording as notedA plain literal is a string combined with an optional language identifier. This may be used for plain text in a natural language. As recommended in the RDF formal semantics [RDF-SEMANTICS], these plain literals are self-denoting.after other changes the text now reads:
Thank you. This wording is better.We believe (again, we claim no special expertise here and would defer to the views of the Internationalization Working Group) that you might usefully add a health warning here. For example... This may, if necessary, be used for plain text in a natural language, but in general this is not recommended; natural language is usually better represented with a more elaborate structure....We hope that you will be persuaded to add a health warning, but we do not believe this point is worth registering a formal dissent for.
The meaning of a literal is principally determined by its character string: it either refers to the value mapped from the string by the associated datatype, or if no datatype is provided then it refers to the literal itself, which is either a unicode character string or a pair of a string with a language tag.
We continue to believe this comment important, but are willing to leave this to your editors' judgement.
A datatype is an entity characterized by a set of character strings called lexical forms and a mapping from that set to a set of values.
The wording given in your response to xmlsch-04 (your section 5 of RDF Concepts) seems to address these concerns adequately. Thank you.
For example, XML Schema requires that the value spaces of xsd:string and xsd:decimal to be disjoint ...This sentence is not exactly wrong, but it seems slightly unusual to use the verb require here, instead of define or something similar. We suggest recasting this as “For example, XML Schema defines the value spaces of xsd:string and xsd:decimal as disjoint ...” (Note, for the record, that the value spaces of all the primitive simple datatypes of XML Schema 1.0 are pairwise disjoint.)
any literal of the form "sss"@ttt^^ddd, where ddd is not rdf:XMLLiteral, treated as identical to the same literal without the language tag, "sss"@dddis "sss"@ddd a typo for "sss"^^ddd?
RDF allows Typed Literals to be given as the object node of arcs. These consist of a literal string (with optional language) and a datatype RDF URI Reference. This is handled ... with an additional rdf:datatype="datatypeURI" attribute on the property element.
Colleagues,The RDF Core WG has considered your last call comment captured in http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-08 (raised in section "4.1. Manifest typing in the instance (policy)" of http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html ) and decided http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0124.html to accept it.The RDF Core WG agrees that there are good reasons for not using rdf:datatype rather than xsi:type.We agree with the XML Schema WG that one reason is that RDF is not restricted to using datatypes defined by XML Schema, but allows other datatypes conforming to the XML Schema model for datatypes.Another reason is that no other RDF/XML attribute takes QNames as arguments. Allowing this in one specific case is also likely to cause confusion.Whilst RDF Core would have preferred to not to introduce a different attribute, it's judgement was that the solution proposed in the last call drafts is the best of the options available.To minimise any confusion, RDF Core has carefully described the correct syntax in both the primer and the RDF/XML syntax documents. We further note that incorrect use of xsi:type where rdf:datatype should be used will be recognised as a syntax error by RDF/XML parsers.Please reply, copying email@example.com whether this response is an acceptable disposition of your comment.Further, more detailed, informal explanation is given below. We assume familiarity with XML Schema datatypes :)RDF Datatypes in instance documents are described in general terms in the section “Typed Literals - rdf:datatype” http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-datatyped-literalsRDF datatypes are identified by URI-references and thus to indicate that a piece of RDF/XML is a datatyped literal, you need to give the URI somewhere. Existing (untyped) literals are used like this:As element content:<ex:prop>foo</ex:prop>As attribute content:<ex:Node ... ex:prop="foo" ... />The latter can be considered as an abbreviation of the former form. The other things that can apply to RDF literals are the in-scope XML language:As element content:<ex:prop xml:lang="en">foo</ex:prop>As attribute content:<ex:Node ... ex:prop="foo" xml:lang="en" ... />(of course xml:lang can be on any outer element)So it was natural to allow datatypes by creating an extra attribute in the property element form. Using it in the attribute form would have meant all the attributes values were of the same datatype (not so useful) and wasn't proposed. Thus a datatyped RDF literal is used in the instance data in the element form with a new rdf:datatype attribute:<ex:prop xml:lang="en" rdf:datatype="http://example.org/dt" >foo</ex:prop> <ex:prop rdf:datatype="http://example.org/dt" >foo</ex:prop>(Note, whether xml:lang values applies to such datatypes/is involved in the datatype mapping is another issue, please don't get distracted!)The above didn't use an XML schema datatype URI in the example above since any datatype is be allowed (identified by a URI).Not in any particular order or necessarily complete, but here is a summary of some issues that RDF Core considered for the RDF/XML syntax on encoding datatypes using xsi:type and why the rdf:datatype solution was decided.
- 1. xsi:type content is an XML Qname not a URIThus cannot indicate any arbitrary datatype URI reference, so another attribute would be needed for that case (like rdf:datatypeURI) - adding two attributes would be worse than adding one.
- 2. XML Qname attribute content in RDF/XMLThis would be the first attribute in RDF/XML to take a XML Qname value (a big step). This would require extra explanation so that existing users wouldn't confuse them with those that took URIs.
- 3. Namespace declarations, prefixesIt would also require instance documents to declare the xsi namespace prefix and have to also check for any namespaces declared inside such xsi:type values and declare those too - again new implementations and explanation needed.
- 4. xsi:type would be confused with rdf:typeSince the former takes Qnames and the latter URI references, it would be possible to get the name wrong and be confused at the errors. Although xsi:type wouldn't be legal everywhere rdf:type was, rdf:type would have been allowed on elements that took xsi:type.
- 5. confusing URIs and QnamesA bad choice of namespace prefixes might make cause other problems in xsi:type values, confusing them for URIs. It would also be more than likely that people would try to use Qnames in rdf:type attribute values.
- 6. xsi:type is illegal in RDF/XML now, unlikely to be used accidentlyIf somebody was tempted to use xsi:type, it would likely cause the parsing to fail. It is only ever used as an attribute in XML Schema documents and to use it on a literal in RDF/XML would be something like this:<ex:prop xsi:type="xsd:string">foo</ex:prop>which is forbidden by grammar production http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#literalPropertyElt
Thank you for your response; we regret to report that we are slightly confused by it.Is ‘The RDF Core WG agrees that there are good reasons for not using rdf:datatype rather than xsi:type’ a typo for ‘The RDF Core WG agrees that there are good reasons for
notusing rdf:datatype rather than xsi:type’? If so, then the rest of the reply makes more sense.We are concerned, however, by point 6 in your informal response. It seems problematic to us to make xsi:type illegal in XML-encoded RDF documents. Among other things, this would make it impossible to validate documents with an XML Schema schema and later process them with an RDF processor.It is also not clear to us that you or we have fully addressed the question of user confusion. The small string distance between rdf:type and xsi:type is almost certain eventually to confuse any user who must use both. Your analysis seems to us to indicate only that you don't really expect any users to be interested in both RDF and XML Schema; we don't think that such users are likely to be all that rare.But since we don't have any better solution to urge upon you, all we can do is gloomily predict user confusion and hope for the best.
Colleagues,The RDF Core WG has considered your last call comment captured in http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-09 (raised in section "4.2. QNames (Editorial, but important)" of from http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html) and decided (http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0138.html) to accept it giving the following explanation:The RDF/XML syntax WD section referred to is paragraph 2 of http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#section-Syntax-intro is the very first section in the document introducing the syntax intended as an overview, not defining the grammar.We accept that this paragraph could be misleading and imply that an XML prefix, and thus only prefixed names, are required.We propose to amend the text in that paragraph to make it clear that in a XML QName the prefix is optional where there is a default namespace either by adding a note or rewording to remove the mention of prefixes.However, we note, the link [Qnames] in the section above already goes to the following definition of QName:QName ::= (Prefix ':')? LocalPart Namespaces in XML -- http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-QNamewhich shows that the prefix part is optional in the current definiton of QNames.This is also mentioned in the errata:
- "Names with no colon can be qualified names." Namespaces in XML Errata -- http://www.w3.org/XML/xml-names-19990114-errata#NE10We also peeked at XML 1.1 CR:which keeps the same distinction.QName ::= PrefixedName | UnprefixedNameNamespaces in XML 1.1, W3C Candidate Recommendation 18 December 2002 http://www.w3.org/TR/2002/CR-xml-names11-20021218/#NT-QNamePlease reply, copying firstname.lastname@example.org indicating whether this is an acceptable resolution of the comment.
Thank you for the clarification.
When an arc in an RDF Graph points to an object node which has no further arcs, which appears in RDF/XML as an empty node element sequence such as the pair <rdf:Description rdf:about="..."> </rdf:Description>, this form can be shortened.seems less clear than it might be. Different readers prove to have different views on what is meant by “the pair <rdf:Description rdf:about="..."> </rdf:Description>”; perhaps it can be replaced by something like “the empty element <rdf:Description rdf:about="..."/>” without loss of precision? Perhaps the sentence could read
When an arc in an RDF Graph points to an object node which has no further arcs, which appears in RDF/XML as an empty node element such as <rdf:Description rdf:about="..."/>, this form can be shortened.
Dear ColleaguesThe RDF Core WG has considered your last call comment captured in http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-10 (raised in section "4.4. Normative specification of XML grammar (policy, substantive)" of http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html) and decided http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0361.html to postpone it.A canonical subset of RDF/XML was considered by the RDF Core WG. However the WG believes that due to the way mixed namespaces are used in RDF/XML it is not possible to define such a subset that:
- a) can represent all the RDF graphs that RDF/XML can represent
- b) can be described by an DTD or an XML Schema.An alternative would be to define a new syntax that is describable with a DTD or an XML Schema but doing so is beyond the scope of RDF Core's current charter. We note that the XHTML WG have expressed interest in working on such a syntax and have been encouraged to do so by RDF Core. RDF Core also welcomes XML Schema's offer to help with this work.We will add this issue to the RDFCore postponed issues list at: http://www.w3.org/2000/03/rdf-tracking/#rdfms-validating-embedded-rdfPlease reply to this email, copying email@example.com indicating whether this decision is acceptable.ThanksDave
Dear ColleaguesThe RDF Core WG has considered your last call comment captured in http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-11 (raised in section "4.4. Normative specification of XML grammar (policy, substantive)" of http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html)The main points you raised in this comment are:
- 1) RDF/XML is defined in "what is very nearly a character-level BNF [which] is at best a missed opportunity and at worst a serious mistake."
- obscuring important parts of the document type
- making it very difficult for the reader to actually understand what is and isn't actually allowed.
- confusing layersRDF/XML is entirely layered on the XML Infoset as defined in Syntax Data Model http://www.w3.org/TR/rdf-syntax-grammar/#section-Data-Model and is not defined at the character-level.All XML detail is handled by the XML specifications, not this document - deployed RDF/XML applications are entirely built on standard XML tools. In layering on the XML infoset, we leave only the important parts of RDF/XML that users and application writers need be concerned about - elements, attributes, whitespace and text.It would have been a mistake to gloss over where, say, the whitespace was significant and where it was ignored - which was one problem with the original RDF M&S specification.
- 2) Rules out XML documents not parsed from character streams (such as DOM)This was explicitly called out:http://www.w3.org/TR/rdf-syntax-grammar/#section-Data-ModelThis model illustrates one way to create a representation of an RDF Graph from an RDF/XML document. It does not mandate any implementation method - any other method that results in a representation of the same RDF Graph may be used.In particular: ...
- This specification does not require the use of [XPATH] or [SAX2]If a DOM interface can provide the very few (4) XML Infoset Infoitems that are needed here, it is not ruled out.
- 3) Suggests a two-step approach first mapping to canonical RDF form constrained by DTD or XML SchemaAn approach using a mapping to a canonical RDF written in XML is related to issue xmslch-10 where we explain why we didn't feel we could do this under the current charter. It certainly would have been useful and helped.The model and grammar used here closely matches how many RDF/XML apps were written, in a token matching style that can be used with standard syntax lexers and grammar generators. This approach has proved suitable after other implementor feedback.The RDF Core Working Group has decided: http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0361.html that the explanation above answers your comment as a clarification.Please reply to this email, copying firstname.lastname@example.org indicating whether this decision is acceptable.ThanksDave
Thank you.We realize that this is a difficult area, but we believe that it would be a mistake for W3C to move forward with a new version of the RDF specifications without undertaking the work of a revision of the syntax.We regret that we must dissent formally from your resolution of this issue. The current mismatch between RDF syntax and off-the-shelf XML tools has not become easier to bear as time goes on; we believe it must be addressed.
Dear ColleaguesThe RDF Core WG has considered your last call comment captured in http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-12 raised in (XML Schema) section "4.5. On the relation between RDF and off-the-shelf XML tools (policy, substantive)" http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html and (Butler) http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0531.html and decided http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0361.html to postpone it.The main points we felt you raised in this comment are:
- 1) RDF/XML
- doesn't match the RDF graph model well
- many ways to write things (elements, attributes, attribute values , ...)
- cannot write a W3C XML Schema, Relax NG schema, XML 1.0 DTD
- "not convienient" to use XSLT, use XQuery, other XML toolsWe know and could give you more problems. However we felt we couldn't fix it all due to the charter constraint:[[The RDF Core WG is neither chartered to develop a new RDF syntax, ...]]Although we note, most of the above XML technologies mentioned above are successfully used with RDF/XML.So we propose to postpone dealing with this in this WG, recording your comments for any future work.
- 2) RDF and XML need not be on different paths
- models, QLs, APIs, editors, tools
- this cleft is not requiredWe encourage work to help integrate better but recognise this is heading into larger web architecture issues.
- 3) Propose that the XML serialization were modified to capture more of the regularity of the RDF data model, offer help.The WG notes your offer of help and has asked the semantic web coordination group to carry it forward.We will add this issue to the RDFCore postponed issues list at: http://www.w3.org/2000/03/rdf-tracking/#rdfms-validating-embedded-rdfPlease reply to this email, copying email@example.com indicating whether this decision is acceptable.ThanksDave
None. (Note: owing to an error in preparing this version of this document, the RDF Core response on this issue was missed and the XML Schema Working Group did not have it in front of them when we approved our responses. The editor of this document has unilaterally suppressed the response originally drafted and approved, since it was predicated on false assumptions.)