[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] RDF Data Access WG Charter
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 . Joe  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.