W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2002

Re: RDF Syntax - simplified Non XML RELAXNG

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Thu, 14 Mar 2002 16:43:11 +0000
To: Jonathan Borden <jonathan@openhealth.org>
cc: www-rdf-comments <www-rdf-comments@w3.org>
Message-ID: <20457.1016124191@tatooine.ilrt.bris.ac.uk>
>>>Jonathan Borden said:
> In my endevours to develop a good XML representation for KIF and N3, I have
> been playing around with extending the RDF syntax. This has highlighted a
> few points regarding the RDF syntax.

We are not considering making large extensions or changes to the
RDF/XML syntax or creating a new one at this time; the RDF Core WG is
specifically not chartered to do this.

> 1) Consider representing bNodes (in NT) as NCNames i.e. no-colon names. RDF
> otherwise disallows non namespace qualified elements and attributes. The RDF
> syntax might use non namespace qualified elements and attributes to
> represent bNodes.

I think that would be confusing to users of the syntax; 
<foo xmlns=""> being for a bnode and <foo xmlns="http://example.org/">
being a (say) property.

> 2) Consider eliminating rdf:_n entirely from the _XML syntax_, that is a
> parser can convert rdf:li to rdf:_2 or whatever. It is not possible to
> create a proper formal grammar for RDF using commonly available tools and
> languages if rdf:_n is allowed i.e. it is not possible to constrain "n" to
> be an integer using any well known XML schema language.

We can't remove this part of the syntax, it is in widespread use.  If
XML schema language can't check all of the RDF/XML, that is
inconvienient but not a death blow to a particular syntax feature.

> It is not readily apparent from reading the Syntax WD how the syntax of
> containers is intended to map onto NTriples. Although this can be deduced
> from the test cases, it would be helpful to describe this in prose, as it is
> a change from RDF 1.

The mapping is in the working draft.  An rdf:li is a property
like any other and handled by the propertyElt production:

  "If element e has e.URI = rdf:li then apply the list expansion
  rules on element e.parent in section 5.27 to give a new URI u and
  set the value of e.URI to be u."

  --   http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20011218/#propertyElt

Which turns rdf:li into a property rdf:_1 (or whatever) which
is then handled by the regular N-triple generating actions.

rdf:li is not allowed as a property attribute hence there is
no mention of it.

The other syntax of containers are the rdf:Seq, rdf:Bag and rdf:Alt
classes which are handled by the nodeElement production just like
any other node:

  "* If for element e, e.URI != rdf:Description then the following
     statement is added to the model:

      e.subject.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <e.URI> .
  " -- http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20011218/#nodeElement

> 3) prohibit use of unknown names in the RDF namespace.

We decided at a recent meeting to not do this, but emit a warning, in
order to not limit defining future RDF names in the namespace
(unlikely, but might happen).

Recorded in our tracking issue:

  "The WG reaffirmed its decision not to restrict names in the RDF
  namespaces which are not syntactic. The WG decided that an RDF
  processor SHOULD emit a warning when encountering names in the RDF
  namespace which are not defined, but should otherwise behave

  -- http://www.w3.org/2000/03/rdf-tracking/#rdfms-rdf-names-use

I feel this is OK since it is similar to how XML handles names
beginning with "xml", expecting later on for others to appear -
for example "xml:base" and "xml:space".

> 4) A simple and easy to include addition to the syntax is to allow nested
> rdf:RDF elements i.e. as the object of a statement. The contents of a nested
> rdf:RDF might be interpreted as a collection of reified statements or as an
> "N3 context" whose set of statements might be interpreted by the MT as
> "unasserted". In any case it is a simple addition to the syntax.

That would be a significant syntax change that we probably can't
justify at this stage in the refactoring of the syntax.  It would
also have implications on the model theory since it would probably
change the model.  Again, this is heading out of our current charter
territory in my opinion.

> Included is a compacted RDF syntax expressed as a non-XML RELAXNG grammar.
> This grammar is also available at: http://www.openhealth.org/RDF/RDFs.rngnx
> You see that it is quite compact.

Yes but it will be when you delete a lot of stuff! :)

> [[
> # RELAXNG non-XML grammar for RDFs - simplified RDF grammar
> # Jonathan Borden 3/7/2002
> namespace local = ""
> namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
> start = RDF
> # rdf:RDF ? allow rdf:ID
> RDF = element rdf:RDF{rdf:ID?,desc*}
> # perhaps unqualified names refer to bNodes
> # var =   element local:*{empty} | attribute local:*{""}
> # an rdf:Description or typedNode
> desc =   subject{predobj*}
> subject =  element (* - (local:*,rdf:*)) |
>     rdf:Description |
>     rdf:Alt|rdf:Seq|rdf:Bag
>    {
>     (attribute rdf:about{anyURI}|
>      attribute rdf:ID{xsd:NMTOKEN})?,
>      attribute rdf:bagID(xsd:NMTOKEN)?,
>      attribute rdf:type{anyURI}?
>    }
> predicate = (element * - (rdf:*,local:*)) | element rdf:li | element
> rdf:value
> predobj =  predicate{
>     attribute rdf:ID{xsd:NMTOKEN}?,
>     attribute rdf:bagID{xsd:NMTOKEN}?,
>     obj |
>     attribute rdf:resource{anyURI} |
>     (attribute rdf:parseType{"Resource"},obj+) |
>     (attribute rdf:parseType{text - "Resource"}, any)
>     } |
>    predAttr
> predAttr =  attribute * - (local:*,rdf:*)| attribute rdf:value {text}
> # this is extended to allow rdf:RDF (i.e. context/bundle) as the object of a
> statement
> obj =   subject |
>    text |
>    RDF
> any =  mixed { element * { attribute * { text }*, any }* }
> ]]
> Jonathan

Thanks for the feedback

Received on Thursday, 14 March 2002 11:43:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:59 UTC