W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2004

RE: Revised draft of CBD

From: <Patrick.Stickler@nokia.com>
Date: Mon, 11 Oct 2004 11:37:51 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A564719B@trebe051.ntc.nokia.com>
To: <tpassin@comcast.net>, <www-rdf-interest@w3.org>

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Thomas B.
> Passin
> Sent: 11 October, 2004 01:17
> To: www-rdf-interest@w3.org
> Subject: Re: Revised draft of CBD
> Patrick.Stickler@nokia.com wrote:
> > And if a CBUD is not a subset of a SCBD, per the present definition
> > of an SCBD, it may be reasonable to modify the definition of an SCBD
> > accordingly to address your use case while still allowing effective
> > use of the minimal URIQA interface.
> If one starts to let in more generalized notions of 
> subgraphs, one needs 
> to make sure that in the euphoria of the envisioned richer data sets, 
> one does not inadvertantly get more than one bargains for.  
> For example, 
> every resource is related to every other, if OWL is in play, because 
> their types are all subclasses of owl:Thing.  I don't think 
> that anyone 
> wants to end up with that in their supposedly bounded subgraphs!

This is precisely why I consider CBDs the most optimal default
form of representation for most applications.

Other applications may need/want something different, but that also
incurs the risk and overhead of larger (perhaps unmanagable) responses.

So while I consider it truly useful to have a number of different forms
of descriptions which are relevant to certain kinds of applications
defined in a standardized manner, so that various services which offer more
than one form of description can all agree on what they contain and
what they are called, etc. we still need a default form of description
that, all other things being equal, works reasonably well for most
applications and avoids most of the scalability/magnitude issues.


Received on Monday, 11 October 2004 08:38:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:53 UTC