Re: Another RDF Syntax Idea

>>>Aaron Swartz said:
> Yeah, I'm sure others have probably suggested something like this already,
> but I figure that now there's a WG to deal with things, we might as well
> start discussing stuff with the knowledge that things could happen. If
> someone has pointers to similar work, please feel free to send them to me or
> post them here. 

Well, we already have several dozen issues, why not add some more,
after all we all have plenty of free time.

> 
> Here are my thoughts on improvements to the XML syntax. These are written
> with the intention to make it easier to migrate XML-based formats to RDF as
> well as making RDF easier to understand. They come from my experience in
> writing RDF modules for RSS and the confusions that people have when
> developing them. Web version at (updated as needed):
> 
> http://logicerror.com/rdf-syntax-idea

In my opinion - the existing RDF/XML syntax will not be thrown away;
it will be clarified and interpreted but not in incompatible ways.
That's what happens when you intend to write systems for use web-wide
- when you say 'W3C Recommendation', that's what you mean.

> 
> 1) Allow attributes. RDF allows the use of either attributes or element
> content, but it shouldn't be an either/or choice. Often time it makes sense
> to use both:
> 
> <price format="dollar">100</price>
>     becomes
> <#URIBeingDescribed> :price [format "dollar"; rdf:value 100 ] .
> 
> (the [] is an N3 convention for specifying an anonymous node)

It already allows both attributes and element content for properties
off a node.  What you are describing is a special case when the
statements have a literal value.  rdf:value is just a property in RDF M&S
and maybe you mean
 
  <#URIBeingDescribed> :price [format "dollar"; rdf:value "100" ] .

unless 100 is some kind of new URI? :-)

Please don't use N3 to explain the XML syntax.  That just confuses
matters since people have to go find an N3 primer first and
understand that.  E.g. need to explain <>, #foo, :something, [...],
';' and '.'

So getting back to your note; you are asking for statements which
have a literal value AND have other properties to be treated as
several statements off a new anonymous node where the rdf:value value
property will be used for the literal value.  i.e. in this case the
statements generated are:

  [URIBeingDescribed] -> [price]   -> [anon1]
  [anon1]             -> [format]  -> "dollar"
  [anon1]             -> rdf:value -> "100"



> 2) Allow element content to be used as an RDF resource. I'm sure others can
> think of a better attribute for this, but it's useful for formats (like RSS)
> that want to remain backwards compatible.
> 
> <format rdf:content="uri">http://example.org/format</format>
>     becomes
> <#URIBeingDescribed> :format <http://example.org/format> .
> 
> (that is, it's interpreted as a URI, not a literal)

  <dc:format rdf:parseType="resourceURI">
    http://example.org/format
  </dc:format>
  
will work in existing parsers; but have no interpretation other than
the content being a literal.  The new parseType could be then defined
in an RDF XML syntax revision as equivalent to

  <dc:format rdf:resource="http://example.org/format"/>

Not sure that's a good idea, not backward compatible.

If we are adding new parseType values, I would like to add base64 for
including large lumps of opaque content e.g. binaries, images or
maybe even RDF in RDF, signed?


> 3) The LI controversy. I'm sure this has been covered plenty, but here's my
> suggestion:
> 
> <items rdf:content="list">
>   <rdf:li rdf:resource="#uri1" />
>   <rdf:li rdf:resource="#uri2" />
> </items>
>     becomes
> <#URIBeingDescribed> :items [
>   rdf:_1 <#uri1> ; 
>   rdf:_2 <#uri2> ;
> ] .
> 
> (the idea is that it points to an anonymous node that's a list)

Chucking out your N3 stuff and using the statement syntax from RDF
M&S; it gives statements

  [URIbeingDescribed] -> items    -> [anon#1]
  [#anon1]            -> [rdf:_1] -> [#uri1]
  [#anon1]            -> [rdf:_2] -> [#uri2]

so what is the benefit of that over:
  [URIbeingDescribed] -> type     -> [rdf:Bag]
  [URIbeingDescribed] -> [rdf:_1] -> [#uri1]
  [URIbeingDescribed] -> [rdf:_2] -> [#uri2]


There may be one, but you don't explain.

> If another term is used instead of rdf:li then an rdf:type will be set for
> the resource.

So in that case, you are using this 'items' thing to tell it is a
container, or is it because rdf:_1 etc. are seen, or are you using
RDFS to check for subProperty of items...?

> 
> 4) An arbitrary document header. Often times, you'll want to RDF-ize a
> format, but can't because of the requirement that rdf:RDF is the root. If
> you add in this element, the format will be incompatible with older tools.
> If you don't add it, no RDF parser will understand it. Solution: the
> rdf:content element, of course. ;-)

The rdf:RDF root is optional, and so is rdf:Description.  Here is a
minimal legal RDF/XML syntax

---
<a:b xmlns:a="http://example.com/ns"/>
---

> 
> <rss rdf:content="rdf">
>     <!-- everything here is interpreted as being inside an rdf:RDF tag -->
> </rss>

Don't need it; this does the same thing and is already in the RDF M&S:

  <rss>
    <x:y rdf:about="http://example.com/r/">
     <!-- property elements / value s-->
    </x:y>
  </rss>

which introduces that x:y is to be interpreted an RDF typed node
(type is x:y) with resource http://example.com/r/ i.e. generating
statements:

  [http://example.com/r/] -> [rdf:type] -> [x:y]
  [http://example.com/r/] -> [...]      -> [..] for property element/values


This has been done by introducing one attribute.

>
> ... large quote with RSS 1.0 example deleted ...
>

We can use RSS 1.0 as a good indication of where there are problems
but I don't think we can change / add lots of new syntax just to make
this easier.  The existing syntax is complex enough with the various
abbreviation forms.

Although I hate to say this - you need to read the RDF M&S more about
the existing XML syntax and understand it thoroughly.  And that is a
couple of months out of anyones life!  :-(

I'm still learning ....

Dave

Received on Tuesday, 13 February 2001 06:00:42 UTC