W3C home > Mailing lists > Public > public-ldp@w3.org > December 2012

Re: Links and graphs

From: Erik Wilde <dret@berkeley.edu>
Date: Thu, 20 Dec 2012 10:28:41 -0700
Message-ID: <50D34AC9.8060108@berkeley.edu>
To: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
CC: mike amundsen <mamund@yahoo.com>, LDP <public-ldp@w3.org>, W3C provenance WG <public-prov-wg@w3.org>
hello graham.

i really appreciate the time you're taking for this discussion! and 
first, just a side note, before getting to the interesting use cases, 
because i think we really have to start from the right place to get this 

On 2012-12-17 16:47 , Graham Klyne wrote:
> On 17/12/2012 17:17, Erik Wilde wrote:
>> there seems to be this lingering feeling that "RDF is different"
>> because "it's semantics, and not a format".
> I wouldn't put it that way, but RDF is different from most of the
> XML-based formats used.  It is a common format that can carry (and
> merge) arbitrary semantics.  That's not true of most other data formats
> on the web.  I don't claim it's unique, and certainly there could be
> other formats with similar capabilities, and they too could be used in a
> similar way to RDF provided that there are media types to distinguish
> the base format.

i absolutely don't want to say that RDF doesn't have some very strong 
abilities in areas where previous formats fell short. it's great as 
schema-less and merge-friendly data format, something that XML can be 
used for, but it gets so complex that nobody (i know of) never went all 
the way of actually implementing it in the most generic way. but while 
RDF's mechanics are much better designed for doing this kind of thing, 
they are not really different. just better designed.

>> ... pretty much all data formats (apart from those
>> using ad-hoc syntaxes) work exactly that way, so there really is not
>> need to
>> deviate from what has been working in the past 20 years.
>> application/atom+xml is
>> atom semantics using xml syntax,
> I would argue that, technically, XML is *not* a syntax.  It's a family
> of syntaxes.  It's a syntactic framework.  Each XML-based document type,
> defined by DTD, XSD, RelaxNG or other means is a syntax, which may have
> ore or less associated semantics.  RDF/XML is an XML-based syntax that
> provides a semantic framework for conveying arbitrary semantics; i.e.
> descriptions of arbitrary things.

you're right that technically speaking, XML actually is not all that 
relevant anymore, pretty much every relevant "XML technology" out there 
today is an infoset or XDM technology, which are the two existing 
equivalents of the RDF abstract model. XML is just one syntax for that 
(EXI is another one), as is RDF/XML or turtle for RDF. in the same way 
as looking at random well-formed XML data doesn't tell you anything 
about the data other than its tree shape (the second XML in 
http://dret.net/lectures/xml-fall10/basics#%286%29 is what i use as 
illustration in XML intros), looking at random RDF data doesn't tell you 
anything about the data other than its graph shape.

>> ... personally, i don't think providing multiple
>> syntaxes is a very good idea, but that's just my personal opinion. but
>> as a
>> matter of fact, pretty much all structured data services today use the
>> exact
>> same setup of "parse the data based on some general-purpose underlying
>> syntax",
>> and then "start processing the data based on some assumption what kind of
>> vocabulary is expressed within that syntax." RDF is doing exactly the
>> same as
>> XML or JSON, just with a different syntax and metamodel.
> I disagree that RDF is doing the same as XML.  It doesn't have any
> notion of syntactic constraints (like DTD, XML schema, etc.)  JSON is a
> more interesting case, as it doesn't (yet) have a way to impose schema
> constraints.

well, if you don't want validation, just use well-formed XML and happily 
work with unconstrained XML trees. the fact that RDF does not have a 
validation model (so far) is not really a feature, it's more of a 
problem, because it makes it much harder to declaratively expose the 
preconditions of a service (POST *this*, and you're fine, otherwise, 
you're hosed).

> And RDF *is* different from both in that id does have a (minimal) formal
> semantics, which neither XML nor JSON have.

you'd be surprised how much you could, if you wanted to, place in the 
XSD type layer, starting from the minimal built-in type layer of simple 
types and their derived types, and then continuing on to complex types 
and their derivation system. it's all horribly designed and not all that 
well supported in popular XML toolkits, so you don't really see many 
apps out there basing all their processing off the XSD type model, but 
you could do that, and then it would be the exact same thing (but only 
trees, of course, and with all the random other limitations XSD has). 
the point being: RDF is much better designed here, and thus people feel 
much more comfortable building their processing on that level, which is 
great and certainly a win. but it's not a unique feature of RDF; it's 
just that XSD has designed this level in a way that nobody wants to use it.

> It's insufficient semantics
> to describe useful things in the world, but it's enough to provide some
> basic ground rules for preserving any meaning that is conveyed, e.g.
> when merging RDF from independent sources.

it's the same thing with XML. if you were an XSD nazi and would always 
type-annotate everything and would only pass around things this way, you 
could build the exact same machinery. only you would claw your eyes out 
several times each day because of how hard it is to do, and because of 
running into all kinds of random limitations.

sorry for this divergence into the good old RDF vs. XML debate, but it 
really helps to look at things this way, because then we can learn where 
we can reuse established patterns of web architecture from a technology 
that has some design pain points (XML for schema-less merging) to one 
that's doing a much better job for these kinds of scenarios (RDF). just 
let's not assume we're doing something new here, where we should be 
applying design patterns in the same way that we have applied them before.


Received on Thursday, 20 December 2012 17:29:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:09 UTC