W3C home > Mailing lists > Public > public-egov-ig@w3.org > April 2010

RE: [dcat] Tomorrow's dcat Agenda

From: Cory Casanave <cory-c@modeldriven.com>
Date: Thu, 22 Apr 2010 11:24:47 -0400
Message-ID: <4F65F8D37DEBFC459F5A7228E5052044A03DE2@DATCENTRALSRV.datcentral.local>
To: "Erik Wilde" <dret@berkeley.edu>
Cc: "Richard Cyganiak" <richard@cyganiak.de>, <public-egov-ig@w3.org>
Dret,
I have made comments [cbc], below.  From my perspective your statements
are not all substantiated.

nope. the web tells you to link resources, to link resources in a way 
that uses a uniform interface, and to expect to interact with resources 
through that interface in a way that allows you to inspect them and then

follow links found in them, to interact with more resources. you can use

whatever representation you like, as long as you make representations of

resources available in self-describing hyperlinked ways. 
[cbc] Something can only be "self describing" if there is some
understanding of the structure that self describes which implies some
agreement on representation.  Of course how much you agree on and the
level of variation can vary.  No data "client" can understand any
logical data model unless there is describing meta-meta data, which is
then a data model.

semweb introduces more constraints on representations (RDF is the only 
acceptable metamodel), 
[cbc] Certainly RDF introduces constraints.  I would classify it more as
a logical data model in that any meta model as any can be encoded into
RDF.

and removes the uniform interface constraint.
[cbc] I don't understand this assertion and don't see how RDF removes
any uniform interface constraint.

so you end up with a style that makes it easier to seamlessly follow the

linked graph, because there is only one metamodel, but you cannot as 
easily have non-read interactions with resources, 
[cbc] Agree that the "CRUD" standards for RDF are not done yet, but
there are CROD interfaces for RDF.  You can use REST as much asa for any
web resource.  It is not true that you cannot have non-read
interactions.  However, there is no MORE or less CRUD capability for the
generic web interface.  You can, however, use the normal REST style of
interactions and this works quite well.

because there is less granularity in the model, 
[cbc] don't understand this either, the granularity is the choice of the
publisher.

and there is no uniform interface.
[cbc] Think this is a false statement.

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

hello cory.

> Interesting statement: architectural style of the web, or that of the
> semantic web.

i think that distinction is at the core of many discussions around the 
narrow or the wide interpretation of what linked data is. i have always 
thought of myself to work on linked data, but some assume i don't, 
because i am not following the RDF approach.

> As it asserts that SEMWEB is distinct from the architectural style of
> the web where as I have thought of SEMWEB as applying the
architectural
> style of the web to data.

nope. the web tells you to link resources, to link resources in a way 
that uses a uniform interface, and to expect to interact with resources 
through that interface in a way that allows you to inspect them and then

follow links found in them, to interact with more resources. you can use

whatever representation you like, as long as you make representations of

resources available in self-describing hyperlinked ways. semweb 
introduces more constraints on representations (RDF is the only 
acceptable metamodel), and removes the uniform interface constraint.so 
you end up with a style that makes it easier to seamlessly follow the 
linked graph, because there is only one metamodel, but you cannot as 
easily have non-read interactions with resources, because there is less 
granularity in the model, and there is no uniform interface.

cheers,

dret.
Received on Thursday, 22 April 2010 15:25:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 April 2010 15:25:12 GMT