OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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]