W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2001

Re: Another RDF Syntax Idea

From: Aaron Swartz <aswartz@upclink.com>
Date: Tue, 13 Feb 2001 07:31:03 -0600
To: Dave Beckett <dave.beckett@bristol.ac.uk>
CC: RDF Interest <www-rdf-interest@w3.org>
Message-ID: <B6AE9337.227D2%aswartz@upclink.com>
Dave Beckett <dave.beckett@bristol.ac.uk> wrote:

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

Thanks for the sarcasm, Dave. Really feel welcomed to the group. Anyway,
it's not another issue -- just a suggestion. Take it or leave it. I want to
make things better and I always thought the W3C was designed to do that. If
it's a matter of time, I'm offering to donate mine.

>> http://logicerror.com/rdf-syntax-idea
> In my opinion - the existing RDF/XML syntax will not be thrown away;

Mine too.

> it will be clarified and interpreted but not in incompatible ways.

Is there anything "incompatible" about my syntax. I don't change anything in
RDF, simply add ways for more triples to be gained. (Well, I guess that some
triples will be interpreted differently now -- perhaps we need an RDF
version number? We can't stop progress...)

> That's what happens when you intend to write systems for use web-wide
> - when you say 'W3C Recommendation', that's what you mean.

Of course. But does this mean we throw out future development on RDF
altogether? What about RDF 2.0 (or really even 1.5).

>> 1) Allow attributes.
> It already allows both attributes and element content for properties
> off a node. 

That's what I said.

> What you are describing is a special case when the statements have
> a literal value. 

Yes. With attributes.

> rdf:value is just a property in RDF M&S and maybe you mean
> 
> <#URIBeingDescribed> :price [format "dollar"; rdf:value "100" ] .

Sorry, fixed it online.

> 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 '.'

OK, I couldn't think of an easier way to write it.

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

Yes. This is what I meant. This is a rather common occurrence that is overly
painful to represent with the current syntax, and an easy addition.

>> 2) Allow element content to be used as an RDF resource.
> 
> <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 [a resource].

You're right this is a better way to do this.

> 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?

Sounds interesting.

>> 3) The LI controversy.
> Chucking out your N3 stuff and using the statement syntax from RDF
> M&S

I don't see this syntax in the spec. What do you mean?

> 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.

I'm simply speaking of the case where you're referencing a Bag or Seq from
another URI. Your thing is basically the same as mine, except you've
replaced [anon#1] with [URIbeingDescribed]. Unless you mean something else.

>> 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...?

Exactly, since RDFS subclassing of container can be unknown at times (and
result in different values) I'm providing a way to state that something is a
contain subclass within the RDF itself, so that it is always properly
parsed.

> The rdf:RDF root is optional, and so is rdf:Description.

Where is this stated? In the spec I see the BNF:

[6.1] RDF            ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>']


> This has been done by introducing one attribute.

If this is true, then I'll shut up now about this.

>> ... 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.

I agree. I'm putting out suggestions. Perhaps not all will be adopted, but
some should be considered.

> I'm still learning ....

Me too.

-- 
Aaron Swartz <me@aaronsw.com>| ...schoolyard subversion...
  <http://www.aaronsw.com>   |  because school harms kids
AIM: JediOfPi | ICQ: 33158237|  http://aaronsw.com/school/
Received on Tuesday, 13 February 2001 08:31:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:48 GMT