Re: [regrep] RDF Data Access WG Charter

[Rex Brooks <rexb@starbourne.com>]

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