W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2008

Re: RIF UCR --> RIF UC

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Fri, 16 May 2008 10:37:26 +0100
Message-ID: <482D55D6.5030908@hplb.hpl.hp.com>
To: Adrian Paschke <adrian.paschke@biotec.tu-dresden.de>
CC: "'Sandro Hawke'" <sandro@w3.org>, public-rif-wg@w3.org

So is the proposal that there will be no requirements in the final set 
of RIF documents?

I can understand the desire to make the UCR document more relevant to 
our current state. However, it does seem a bit cheating to loose the 
requirements - especially since one could debate how well the current 
design meets them all. Is the proposal to put the requirements on a web 
page or something instead?

Also could you explain more what you mean about "tailoring the use cases 
to BLD"? Surely the UC(R) document is about RIF not BLD. Several of the 
original use cases are not motivated by specifically logic dialects and 
don't use function symbols, equality etc.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England


Adrian Paschke wrote:
> Hi Sandro,
> 
> The feedback from the three reviews (below) indicates that requirements and
> critical success factors should be removed (i.e. UCR would become UC), and
> that the use cases should be represented in the syntax and semantics of RIF
> FLD/BLD -- guiding others to RIF. I already started representing the current
> use cases, but several further updates and new examples are needed. 
> 
> Since RIF BLD and FLD are now more stable and UCR has been considered as an
> important phase 1 publication, it is now the prefect time to discuss the
> final phase 1 shape of UC(R), so that I can finish my work on it.
> 
> 
>>From Igor’s review:
> 
> Requirements seem irrelevant at this stage and should
> be dropped from the title, and Critical Factor Analysis
> is also mostly irrelevant.
> The main purpose of the UC document should be motivation
> for RIF and illustrations how FLD/BLD address various
> aspects of use cases.
> 
> 
>>From Chris’s review:
> 
> Up until now, the UCR document has provided us a set of requirements, as
> well as some "design constraints" that have guided our design of BLD.  Going
> forward, the UCR document will serve as a publicity vehicle for RIF.  It's
> purpose is not to guide us anymore, but to guide others to RIF, to explain
> as simply as possible what RIF dialects are for and why anyone should
> consider using them.  It should not be a tutorial, focusing on the "Why use
> RIF"? questions and not "How to use RIF", but it should do this with clear
> motivating examples (i.e. Use Cases) expressed in the syntax&semantics we
> have developed.
> 
> 
>>From Gary’s review:
> 
> What I would expect from the UCR:
> Use cases that motivate and illustrate the proposed Phase I technical
> solution (FLD/BLD and XML/RDF/OWL integration).  Some consistency amongst
> the use cases, including using the same syntax (some simplified FLD
> presentation syntax) and describing how to access XML or RDF data as frames.
> 
> What I get upon reading the UCR:
> Use cases with little consistency amongst themselves (not guided by the same
> solution) and that claim to motivate a questionable hierarchy of "critical
> success factors".  The document is useless as a tutorial or primer to the
> technical specification. 
> 
> -Adrian
> 
> -----Ursprüngliche Nachricht-----
> Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im
> Auftrag von Sandro Hawke
> Gesendet: Donnerstag, 15. Mai 2008 20:20
> An: Adrian Paschke
> Cc: public-rif-wg@w3.org
> Betreff: Re: RIF UCR --> RIF UC 
> 
> 
> 
>> As you recommended, I will split off the requirements so that UCR becomes
>> RIF UC and will further tailor the use cases to RIF BLD.
> 
> I'd want to hear and think about this more before endorsing such a move,
> as (I imagine) would most of the rest of the WG.
> 
> Can you summarize the idea and the arguments?
> 
>     -- Sandro
> 
> 
Received on Friday, 16 May 2008 09:51:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:48 GMT