[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] RDF Data Access WG Charter
Rex, This is the key " Let the solutions speak for themselves". I've found the W3C members are at least open to looking at other peoples specifications - they will at minimum do due diligence to see - and as you say - being overworked - will seize chance to take easy-outs - or the Borg approach - "You have been assimulated". I think the later outcome is what we are hoping for - that they start drinking the Cool-aid even if they change all the <tagnames> to protect the innocent. DW. ----- Original Message ----- From: "Rex Brooks" <rexb@starbourne.com> To: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM> Cc: "John Gillerman" <john.gillerman@sisconet.com>; <regrep@lists.oasis-open.org> Sent: Friday, January 02, 2004 2:24 PM Subject: Re: [regrep] RDF Data Access WG Charter > Suggestion: Approach the W3C with some care. I've had several folks > regale me with tales of arrogance and suspicion, which I take with a > largish grain of salt. However, simply in terms of group dynamics and > territoriality, I would also suggest one or both of two approaches. > > 1. Present yourselves as equally busy and overworked, too. This > establishes a common experiential base, and is only true, after all. > Say that you have been working in this area and have produced some > specs, then list them. Then say that your interests appear to > converge with theirs in this arena, and that you have discovered a > set of requirements they may find useful and instructive, too. Then > list these requirements and how you have explored meeting those > requirements. Try to sound neutral, not dedicated to your solutions. > Let the solutions speak for themselves and make it clear that you are > keeping your options open. But, DON'T elaborate on how inadvertent, > or even deliberate, conflicts could seriously inconvenience all > parties or invalidate the existing work of some parties and > constituencies, and DON'T tout the benefits of your work in this > area. Few things are more off-putting, while it is almost always a > guaranteed win if all one suggests is opening a dialog. > > 2. Indicate, and understand how, a formal liaison between your groups > can be mutually beneficial. Most of us dread the word "formal" and I > have found that it is sometimes magical in its ability to forge > consensus. My own experience is that, failing consensus, formal > working liaisons can forge workable solutions despite a lack of > consensus. > > As for myself, I usually make it clear by implication that failing to > reach common ground is going to benefit no one, and make everyone's > future work more difficult. > > Keep smiling, > Rex > > > P.S. Idealism is at least as fine an idea and pastime as conspiracy > theory. For either, lots of observation and a long view is helpful. > > At 10:11 AM -0500 1/2/04, Chiusano Joseph wrote: > ><Quote> > >To be very clear, the ideal situation from my perspective is that RDF DA > >WG accept ebXML Registry V4 as RDF DA API and help us meet all > >requiremjents identified for RDF DA. > ></Quote> > > > >Not to discourage by any means, but realistically what are the chances > >that that will happen? > > > >Joe > > > >Farrukh Najmi wrote: > >> > >> John Gillerman wrote: > >> > >> >Farrukh, > >> > > >> >I did not mean to comment on the existing RDF Net API submission, but on > >> >what could eventually be standardized by the RDF DA WG. > >> > > >> That clarifies things a lot. RDF Data Access spec is not yet defined and > >> can be influenced. My previous email suggested that ebXML Registry API > >> should be proposed as input to the RDF DA API. > >> > >> >My own personal > >> >opinion is that there might be time to help shape requirements. > >> > > >> +1 that is just what I was suggesting. > >> > >> > In this > >> >case, it is unclear if the eventual RDF API would fit the bill. Do we know > >> >that the RDF DA WG wouldn't consider the requirements for federation, event > >> >notification, and the others? Seems like a good API for a use > >>case such as > >> >a semantic data grid would include these things. > >> > > >> > > >> To be very clear, the ideal situation from my perspective is that RDF DA > >> WG accept ebXML Registry V4 as RDF DA API and help us meet all > >> requiremjents identified for RDF DA. > >> > >> >With regard to the applicability of RDF, I am no expert, but had thought > >> >that RDF could refer to non RDF content. Am I off base here? > >> > > >> Yes but it does not get into access control, federation etc. > >> > >> >Couldn't an > >> >RDF API support the uploading of non RDF based content to a server? > >> > > >> It could but RDF Net API does not. If ebXML Registry V4 API was the RDF > >> DA API then it would naturally. > >> > >> >... > >> > > >> > > >> > >> >With regard to the current API, has the team considered an API that is > >> >content and state neutral. I may be completely confused here and rehashing > > > >old discussion, but doesn't the API have content and state > >specific parts in > >> >it? > >> > > >> Your suggestions makes sense and fortunateley this is already the case. > >> The ebXML Registry specs are totally content neutral though XML content > >> has some special support in certain areas. The API is a stateless API. > >> > >> >I had thought that your vision of web servers is to the web as ebXML is to > >> >the semantic web implied that ebXML would be designed not only for intra > >> >enterprise integration as well as inter enterprise integration. Do people > >> >think that the current API applies well to this more general use case (one > >> >that scales down to connecting to local apps together). In this case the > >> >RIM is just an information model that each server could expose. > >> > > >> > > >> ebXML Registry is being used intra and inter enterprise today. In both > >> cases the RIM as well as the ebXML Registry RS API is used. Using the > >> API does not mean you need multple registry federations. Both RIM and RS > >> API are required in all cases. > >> > >> >I am all for extending/maintaining the current RIM, but am wondering if the > >> >current one can't be modeled using RDF (from an interface > >>perspective only). > >> > > >> > > >> That is indeed the long term vision I articulated in last email. In the > >> long term vision the RIM is entirely mapped to and expressed in OWL/RDF. > >> In this vision the underlying metamodel is OWL/RDF while the information > >> model is RIM. RIM would be a special OWL ontology in this vision that > >> could be extended by verticals, site admins and end users based on > >> specific needs. In this long term vision any other OWL ontology or RDF > >> content ma also be submitted to the registry as extension to RIM. > >> > >> >Could an RDF interface be used to browse and query without > >>changing the RIM? > >> >Would this be a too radical departure from current ebXML technology? > >> > > >> > > >> That is the fundemental issue. The long term vision of moving RIM to > >> OWL/RDF is too radical a departure and effects implementors and > >> end-users to drstically and abruptly. That is why I mentioned a two > >> phased incremental approach. The first phase (version 4?) would not > >> change existing RIM but just extend it by adding incremental support for > >> publish/discovery/use of OWL/RDF into the registry. One could begin to > >> use Ontologys instead of ClassificationSchemes for classification and > >> discovery. > >> > >> Later (maybe in version 5?) we could move RIM to OWL/RDF and meet our > >> longer term objectives. This would make RIM completely type and > >> attribute extensible. > >> > >> >I agree that ebXML Registry goes beyond an RDF API since we > >>specify content. > >> > > >> > > >> To be clear I said RDF Net API submisison and not RDF DA WG deliverables > >> which are yet to be defined. > >> > >> >I don't mean to be a skeptic, but I don't believe that the ebXML API would > >> >be a good RDF API. I think that some believe that RQL would make > >>a good RDF > >> >API and it is simpler as well as being content and state neutral. > >> > > >> > > >> I feel that ebXML Registry version 4 API could be geared to meet the > >> requirements of the RDF DA WG and as such would be a great RDF DA API > >> (by design not by accident). > >> > >> Thanks for contributing to this stimyulating discussion. > >> > >> -- > >> Regards, > >> Farrukh > >> > >> To unsubscribe from this mailing list (and be removed from the > >>roster of the OASIS TC), go to > >>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgrou p.php. > >Content-Type: text/x-vcard; charset=us-ascii; > > name="Chiusano_Joseph.vcf" > >Content-Transfer-Encoding: 7bit > >Content-Description: Card for Joseph Chiusano > >Content-Disposition: attachment; > > filename="Chiusano_Joseph.vcf" > > > >Attachment converted: Enterprise:Chiusano_Joseph 335.vcf (TEXT/ttxt) > >(002AF31A) > >To unsubscribe from this mailing list (and be removed from the > >roster of the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup .php. > > > -- > Rex Brooks > GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth > W3Address: http://www.starbourne.com > Email: rexb@starbourne.com > Tel: 510-849-2309 > Fax: By Request > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]