RE: Revised draft of CBD

> -----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.

Regards,

Patrick

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