RE: On the treatment of Design Objectives?

I would prefer to concentrate on a common core functionality.  I don't think
the WG can get it right first time but it can stabilise a useful core on
which to build the next wave of query-driven applications.  The web in
semantic web is about a set of core functionality that any system can rely
on.  Not a perfect solution to one applications needs but a core set that
can be used by large numbers of systems. to get stuff done.

There already has been a round of implementation experience with RDF query
languages over the last few years and there are a significant number of
users out there using QLs in toolkits they have downloaded (that is, the
users didn't write themselves - they are users of the QL).  Despite
syntactic and other differences, there is a common set of functionality that
these languages provide as well as features that are often requested.  We
should focus on that and make that all work together.

	Andy

-------- Original Message --------
> From: Yoshio FUKUSHIGE <>
> Date: 12 May 2004 01:43
> 
> Hello,
> 
> Dan said:
> > > If we don't make optional protocol elements, developers could
> > > invent their own protocols for the functionality, which will lead
> > > the interoperability. 
> > 
> > That's natural and good, no? Implementation experience should
> > come before standardization.
> 
> Well...
> The later the standardization, the more the adapting cost would be, I
> think. 
> And an optional functinality of type (2) in my wording (i.e. those
> relatively easy to make standards for, but not suitable to force all
> implementations to support) should have enough implementation
> experience by 
> now.
> 
> If the situation is that there's no functionalities of such kind, then
> our 
> discussion ends.
> I'm happy with not having those of type (1) in the specification or
> leave 
> them just as "desin objectives."
> ... type(1): those which would require too much time to make standards
> for 
> 
> > For every optional feature of a specification, there's a risk
> > that party A requires it and party B chooses not to provide it,
> > and hence A and B do not interoperate, even though it looks
> > like both conform to the specification.
> 
> In this case, the server B could answer to the client A
> "Sorry, we don't support that feature, will you say it in other words?"
> or "Sorry, all we can give you is this (providing its best answer)"
> and A shoud be ready for it, for the optional features is labeled
> OPTIONAL 
> in the specification.
> 
> > Perhaps the fault is on party A for depending on a feature
> > that's not guaranteed to be provided. Then in fact noone
> > can rely on the feature, so it's not really standardized
> > after all. Why keep it in the specification?
> 
> It's to provide further interoperability among languages that support
> the 
> optional functionalties.
> 
> > Perhaps the fault is on party B for not providing a
> > needed feature. Then why was it optional? Why was B
> > not required to provide it?
> 
> It's because optional functionality could be burdonsome for small
> servers (and maybe so for some clients, too?).
> 
> If we keep some functioality OPTIONAL, providers who want to implement
> only 
> the mandatory part of the specification
> can provide more compact servers.
> 
> In other words, OPTIONAL requirements are the ones to be included in the
> future specification
> when computational or device costs should be considerably lower than
> now. 
> 
> > In quite a few cases, W3C specs do have optional
> > features, but these come at a cost, and that cost
> > ought to be justified.
> > 
> > It's almost always better to make separate, smaller,
> > orthogonal or layered specifications than to have
> > specs with optional features. Then party B can
> > make a clear claim to conform to "WidgetML basic"
> > and not the "WidgetML hyperspeed extension", and
> > party A, who needs to go at hyperspeed, will know
> > to shop for it by name.
> 
> I agree with you on this point.
> It should be better.
> 
> My consern, however, is that the costs to support each optional features
> coud be differ (or couldn't be shared),
> and without some theoretical justification, our layering/clustering
> functionalities wouldn't get people's support.
> "Why should I implement the optional functionality B paying extra cost
> when 
> I need only A?"
> # In OWL case, we have theoretical justification, don't we?
> 
> > > And I think at least 4.3 Non-existent Triples and 4.4
> > > User-specifiable Serializatin belong to type (2).
> > > 
> > > 4.5 Aggretate Query seems difficult, but it is indispensable in UC
> > > like 2.4 and 2.6 where user client queries to more than one DB.
> > 
> > OK, now that you're more specific, I see your point.
> > 
> > But if there are features that are outside a core that absolutely
> > every implementation needs to provide, I would much prefer not to
> > spend the time to standardize them in our first version, even if
> > they would take less time than some other features.
> 
> I want to know other members' opinion on that point.
> 
> Best regards,
> Yoshio

Received on Wednesday, 12 May 2004 08:21:32 UTC