] > Resource Description Framework: Base DSD Schema This DSD-2 schema provides a minimal definition of the Resource Description Framework. It provides a baseline skeleton for higher level definitions such as RDFS and OWL into which it should be included. It has been difficult to produce this schema as there have been so many gaps in the formal grammar of RDF. The following represents the best fit so far against the current specification together with additional parts of the grammar left out. Some terms have been declared but not used, their use will be declared in higher level schemas for RDFS etc. The schema represents work in progress so any help here would be gratefully received. Any bug reports, help, suggestions, new task schemas etc to me, Hugh Field-Richards. I will include them as soon as vacations, weekends, work etc allow. Note that the member attributes of the form "rdf:_n" cannot be catered for by DSD (or any other schema for that matter) — it ain't the right grammar. Created Heavily modified in all areas! First released version Added externally accessable rules "rdf." Split off from original rdf.dsd Complete rewrite according to latest syntax. Major change to documentation (XHTML) and namespaces Another major rewrite with improved DSD syntax. Added extra vocabulary. Several tweakings to cater for empty elements. Hugh Sherwood Field-Richards h.field-richards@eris.qinetiq.gov.uk St Andrew's Road Room G13 QinetiQ Malvern Worcs United Kingdom WR14 3PS All copyright, database rights and other intellectual property in this software is the property of QinetiQ limited. The software is being released free of charge for use in accordance with the terms of open source initiative GNU General Public Licence. QinetiQ Ltd does not verify or warrant the accuracy, completeness or suitability of this software for any particular purpose. Any use of this software whatsoever is entirely at the user's own risk and QinetiQ Ltd accepts no liability in relation thereto. Element Expressions This defines a set of valid elements grouped as the specification. Note that the latter is presented in terms of variable names for the elements and attributes. We cannot do this in DSD — or for that matter in any other schema language except possibly RELAX NG. But that schema will only allow us to do it with the element names but not attributes. Core Syntax Terms "rdf:RDF" | "rdf:ID" | "rdf:about" | "rdf:parseType" | "rdf:resource" | "rdf:nodeID" | "rdf:datatype" The same as above except when for contents. This is repeated for all the vocabulary definitions below. Old Terms "rdf:aboutEach" | "rdf:aboutEachPrefix" | "rdf:bagID" These are the names from the RDF vocabulary that have been withdrawn from the language. Container Terms "rdf:Bag" | "rdf:Seq" | "rdf:Alt" These terms have been left out of the current RDF spec — I do not see why. They reappear in the RDFS spec but are given namespaces from the RDF, which I believe, means that they should appear in the RDF spec. Reification Terms "rdf:Statement" | "rdf:subject" | "rdf:predicate" | "rdf:object" Collection Terms "rdf:List" | "rdf:first" | "rdf:rest" | "rdf:nill" Class Terms "rdf:XMLLiteral" | "rdf:Property" Utility Terms "rdf:value" Extra Terms These are the set of terms that do not appear int the ordinary grammar Syntax Terms coreSyntaxTerms | "rdf:Description" | "rdf:li" Note that these syntax terms are not used anywhere. Attribute Definitions ID nodeID about resource datatype parseLiteral parseResource parseCollection parseOther bagID Restriction on Property Elements propertyElementURIs ::= anyURI - ( coreSyntaxTerms | "rdf:Description" | oldTerms ) The URIs that are allowed on property elements. Attribute Definitions As was said we have to redefine all the above for attributes Attribute Production coreSyntaxTerms "rdf:RDF" | "rdf:ID" | "rdf:about" | "rdf:parseType" | "rdf:resource" | "rdf:nodeID" | "rdf:datatype" Old Terms "rdf:aboutEach" | "rdf:aboutEachPrefix" | "rdf:bagID" These are the names from the RDF vocabulary that have been withdrawn from the language. Restrictions on Property Attributes propertyAttributeURIs ::= anyURI - ( coreSyntaxTerms | "rdf:Description" | "rdf:li" | oldTerms ) The RDF URI references that are allowed on property attributes. Any element within the rdf namespace can have any rdf attribute. Any restrictions to this are defined below. I am assuming that the all RDF vocabulary elements can have the ID attribute. This may prove a rash assumption. I am also permitting any RDF element to contain attributes from the XML namespace: xml:base, xml:lang, etc.. Node Elements Node Element Exceptions nodeElementURIs ::= anyURI - ( coreSyntaxTerms | rdf:li | oldTerms ) Note that the anyURI means any within the RDF namespace here. We can provide further additions to this within higher level schemas. A List of Node Elements nodeElementList ::= ws*, ( nodeElement , ws* )* DSD removes and processes whitespace by default so we can make a simplification here. A Single Node Element Node Element nodeElement ::= start-element( URI == nodeElementURIs ) attributes == set( ( idAttr | nodeIdAttr | aboutAttr )?, propertyAttr* ) ) ) propertyEltList end-element() Note that propertyAttr is defined as any URI except a set of RDF URIs (see above). This means the contenttype rdf.propertyAttributeURIs is defined without the zero or more repeats. Any further restriction for a particular schema is done within that schema at a higher level. Looking at the attributes here we have the following that are allowed: rdf:ID, rdf:resource, rdf:nodeID and any defined by propertyAttr. Note that the attributes rdf:ID, rdf:resource and rdf:nodeID are also defined in coreSyntaxTerms and are therefore excluded in propertyAttributeURIs. So emptyPropertyElt both allows and disallows these attributes; while it will probably be argued that everyone knows what is meant, this is sloppy specifying. The end result is I have to specify the requirements in the boolexp below. Only one of these three attributes are allowed. Any of the remaining attributes in the rdf namespace have to follow the exclusions. Property Elt List propertyEltList ::= ws* , ( propertyElt , ws* )* propertyElt ::= resourcePropertyElt | literalPropertyElt | parseTypeLiteralPropertyElt | parseTypeResourcePropertyElt | parseTypeCollectionPropertyElt | parseTypeOtherPropertyElt | emptyPropertyElt This is a slightly problematic definition. I can make a reasonable assumption that all the above resolve to a common element set (propertyElementURIs), but with a different attribute set. The content of each will be different dependent on the attribute and this is attempted in the rules that follow. The rule that follows should be used where rdf.propertyEltList appears. Resource Properties Resource Property Elt resourcePropertyElt ::= start-element( URI == propertyElementURIs ), attributes == set( idAttr? ) ) ws* nodeElement ws* end-element() I have to have the rather mucky boolexp below as the RDF syntax is so crass. Remember that any RDF namespace element can have an RDF attribute. The rather nasty equiv expression here is saying "not( rdf:* ) except rdf:ID" (I hope). Literal Property Elt This expression defines what is classed as a literal property. Note that the expression is not unambiguous and overlaps with others below. literalPropertyElt ::= start-element( URI == propertyElementURIs ), attributes == set( idAttr?, datatypeAttr? ) ) text() end-element() This expression defines what is classed as a literalPropertyElt. It includes the possible content but it still has an ambiguity problems. Parse Type Literal Property Elt parseTypeLiteralPropertyElt ::= start-element( URI == propertyElementURIs ), attributes == set( idAttr?, parseLiteral ) ) literal end-element() The definition of what is allowed in the "literal" content is defined at higher levels. However we can say it must not be character data. This expression defines what is classed as a parseTypeLiteralPropertyElt. Parse Type Resource Property Elt parseTypeResourcePropertyElt ::= start-element( URI == propertyElementURIs ), attributes == set( idAttr?, parseResource ) ) propertyEltList end-element() This expression defines what is classed as a parseTypeResourcePropertyElt. Parse Type Collection Property Elt parseTypeCollectionPropertyElt ::= start-element( URI == propertyElementURIs ), attributes == set( idAttr?, parseCollection ) ) nodeElementList end-element() This expression defines what is classed as a parseTypeCollectionPropertyElt. Parse Type Other Property Elt parseTypeOtherPropertyElt ::= start-element( URI == propertyElementURIs ), attributes == set( idAttr?, parseOther ) ) propertyEltList end-element() This expression defines what is classed as a parseTypeCollectionPropertyElt. It includes the possible content but it still has ambiguity problems. Production emptyPropertyElt emptyPropertyElt ::= start-element( URI == propertyElementURIs ) attributes == set( idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*)) end-element() It should be noticed that resource is declared twice in the production for emptyPropertyEllt, once explicitly and once as an exclusion in propertyAttr. To overcome this I have had to expand everything here and not use previously defined rules. Nasty but necessary This expression defines what is classed as a emptyPropertyElt. It includes the possible (no) content but it still has ambiguity problems. Containers rdf:Seq and rdf:Bag both contain list items but can be a null list. Note that there is no formal defintion of these elements. String Types This needs extending as required RDF URI String Type The RDF spec says: "RDF URI references are compatible with the anyURI datatype as defined by XML schema datatypes [XML-SCHEMA2], constrained to be an absolute rather than a relative URI reference."