Re: [regrep] RDF Data Access WG Charter

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<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.
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard