Re: Links and graphs

Hey Erik, all,

you now seem to pick up the old XML vs. RDF debate and argue that XML
is semantically capable of a lot that RDF can do.

I wonder how this aligns with your own ACM article "XML fever" from
2008 where you state that "Semantic Web technologies have little to do
with the plain Web and XML" and "Semantic Web concepts and tools are
prerequisites for knowledge-intensive computation", etc.?

Here's the link: http://queue.acm.org/detail.cfm?id=1466454

Martynas
graphity.org

On Thu, Dec 20, 2012 at 7:28 PM, Erik Wilde <dret@berkeley.edu> wrote:
> 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 right.
>
>
> 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.
>
> cheers,
>
> dret.
>

Received on Saturday, 22 December 2012 13:01:19 UTC