- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 12 May 2004 13:06:49 +0100
- To: Yoshio FUKUSHIGE <fuku@w3.org>, "'RDF Data Access Working Group'" <public-rdf-dawg@w3.org>
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