Re: DTD for RDF? How is that possible?
From: Roger L. Costello <costello@m...> >I recall seeing a posting a few months back where someone posted a DTD That was me! See http://www.ascc.net/xml/en/utf-8/resource_index.html >for RDF. Upon reflection I find this puzzling. How could you possibly >create a DTD for RDF? Not at all. It was trivial to make a DTD for almost all of the RDF syntax. I think the DTD is a lot clearer than their formal syntax. In fact, their formal syntax leaves out rdf:subject, rdf:object, rdf:predicate, rdf:type and rdf:type. I have put these in today. The only thing that eludes DTDs is the unlimited number of rdf:_n attributes; I have put in 8 and you can add as many more as you need; they seem a particularly gratuitous carbuncle on RDF to me: I trust everyone will boycott that abbreviated form (the GratAbbCarb ?). >It is my understanding that RDF documents can only be "well-formed". >There is no such thing as a "valid" RDF document. Correct? /Roger But for any particular group of documents you can make up a DTD for them. And you can use a variant of the DTD to constrain your users to prevent them from using the rdf:_n attributes. That would be a prudent move. So in fact you can have lots of DTDs which generate data that complies with RDF. And you can generate a DTD (like mine) which should accept any RDF document (providing, of course, that you include complete the DTD to include any domain-specific element names: these can be included in the internal prolog). >... By definition, the child elements in >rdf:Description are arbitrary: > ><!ELEMENT rdf:RDF (rdf:Description)*> ><!ELEMENT rdf:Description (???)*> > In order to think about the DTDs, we need to split the structure into levels: * The first is the direct structure (this is the DTD that I give)--it says that an rdf:RDF element has a declared content type of ANY--that is easy, and it is what the RDF spec says, under all the fluff; Similarly, rdf:Description can have a content model of ANY. It is important to realize that "ANY" signifies this arbitrariness... * The second is the "architectural" structure (I didn't give a DTD for this: I just put it in comments and a parameter entity; I could have used ISO's Architectural Forms declarations to declare this architectural structure): this says that a child of an rdf:RDF must be ( rdf:Description | rdf:Bag | rdf:Set | rdf:Seq ) and gives the appropriate attributes for these. Because these are architectural elements, they do not have to be signified in the element type identifier (i.e., you can use any name, as long as you have the correct attributes and the correct content models). Rdf:Description would have an architectural content model of (rdf:PropertyElement )* and the rdf:PropertyElement has its due attributes. So conventional DTD modeling sees this as two structures, each of which can be described using DTDs. Since the RDF people didn't use architectures, they are forced to use BNF (which is incomplete w.r.t. XML, and incomplete and confusing w.r.t. RDF) and are banished to cry for other forms of extended context declarations. The document can be validated against the direct DTD only, but the indirect DTD, if constructed, could be used to valid using an architectural validator. (Probably that XAF tool could do it. You could also use XSL to do this kind of validation: I have an article on the same site "Using XSL for Structural Validation" which looks into it: of course, unless XSL has some way to check for names generated from numbers, it cannot validate all possible rdf:_n attributes, but that is a flaw in RDF.) At least the RDF stands as a notable application that doesn't use the direct element type identifier to key the content model. Following Murata Makoto's excellent XTech99 talk about performing set operations on content models, I have been a little afraid that other forms of validation (e.g. architectural validation using attribute names, or content model validations that follow IDREFs instead of subelements) have been thrown out. Which is a shame, because parallel content models provide some nice capabilities (as RDF may, in about a million years, prove). I still find it difficult to see RDF as anything other than a way of making implicit relationships, which every DTD designer builds into their DTD, explicit. This allows generic tools which understands the relationships. But the generic tools still need to understand the schemas, so I think RDF does not take us very far in practise, apart from the drab tasks of managing, navigating and visualizing. It is not a very thick layer, so it is a pity they have such a restrictive syntax: the whole thing should have been an architecture that could have been retrofitted to any existing DTD. A great opportunity missed, IMHO. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format