RE: [dcat] Tomorrow's dcat Agenda

Erik,
Re: yes, and what i wanted to do was to point out the differences
between the architectural style of REST, and that of semweb. they are
not the same
[cbc] All I can tell you is we and many others use REST interfaces to
RDF graphs and it works very well (including SPARQL at the same
endpoint) - REST & RDF are orthogonal just like XML and REST are
orthogonal.

RDF graphs are "documents".

-Cory

-----Original Message-----
From: Erik Wilde [mailto:dret@berkeley.edu] 
Sent: Thursday, April 22, 2010 2:14 PM
To: Cory Casanave; public-egov-ig@w3.org
Cc: Richard Cyganiak
Subject: Re: [dcat] Tomorrow's dcat Agenda

hello cory.

> I'm sorry but I find this highly bias, I'm not sure what you are
trying
> to prove/disprove.

i was trying to answer your initial question about the difference 
between web architecture and semweb architecture.

> [cbc] Yes, there exists the SPARQL specification and I have written
> previously about the lack of connection between a SPARQL endpoint and
> the RDF graph.  My suggestion is that all RDF resources should be able
> to respond to SPARQL at the same address, but that is not standard at
> this time.  However, XML "has" xQuery with the same issues.  But, we
are
> talking about RDF - not every RDF related speciation.

sure. XQuery is back-end technology and may be used to implement RESTful

services that expose XML. or you may build those with XSLT, or with 
SQL/XML. that's an implementation question of the back-end. your RESTful

service allows people to GET/PUT/POST/DELETE XML documents.

> [cbc] The graph IS the unit of granularity, and a graph can be huge or
> tiny just like an XML document can.  There is nothing inherent in the
> RDF logical model or the XML model that specifies the granularity with
> which it will be used.  You could have a graph that corresponds to a
row
> in a DBMS or the entire DBMS.

XML has the concept of a document, which RDF doesn't have. this can be 
very inconvenient, such as when you want to work with a large set of 
those documents, but it is this level of being able to package related 
data in one unit (which often people refer to as supporting "coarse 
grained" interactions) which is not there as a first class concept in 
RDF. or, putting it differently, in XML, you can see three levels:

- individual nodes in the XML tree (elements, attributes, ...)
- the XML document (which can be tiny or huge)
- the set of all XML documents connected by links

in RDF, there are two levels:

- triples
- the graph of all the triples you know of.

another important difference is that in REST, the most important concept

is that of a resource which has a URI because then it is possible to 
link to this URI and interact with the resource using the uniform 
interface. in semweb, the most important concept is that a resource has 
a URI because then it is possible to describe the resource by making 
assertions about that URI, instead of interacting with it.

> But, every solution has issues it is just a matter of which one(s) we
> are going to vest in so that we don't have the information
fragmentation
> problems we do now.  Of course we can always invent new ones, but
people
> are getting tired of that.

yes, and what i wanted to do was to point out the differences between 
the architectural style of REST, and that of semweb. they are not the 
same (one focuses on interactions *with* resources, the other on 
description *of* resources) and both have advantages and disadvantages 
for certain use cases, exactly like you say.

cheers,

dret.

Received on Thursday, 22 April 2010 18:20:11 UTC