Re: [regrep] RDF Data Access WG Charter

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

BTW I envision the day when we will have a sort of "Registry Net API"
that is programming language/platform-agnostic, and that can be used for
operations on registries regardless of what "type" of registries they
are. We could have a "super" query for query of registries (among other
types of operations) that is roughly equivalent to the Net API query
operation [1].

Joe

[1] query(ModelReference, Query, QueryLang, ResultsFormat) =>
StatementSet

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.