Re: [regrep] RDF Data Access WG Charter

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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