RE: [regrep] RDF Data Access WG Charter

["John Gillerman" <john.gillerman@sisconet.com>]

Farrukh,

Seems like we are discussing two central issues.  First, will the RDF API
meet our needs (it it our own then obviously yes) and what are the issues
related to working with this group with regard to getting our work done.
Second, what is the best RDF migration strategy.

With regard to the former, I would hope that we can get them to see the
ebXML registry as a important use case and that their schedule matches up
with what we have in mind.  Seems like we might be able to get a sense of
their willingness fairly easily.  It might be good if we picked someone from
our group to be lead liaison with the RDF API WG.  That way we can use that
person as a point of synchronism for our input.

With regard to the later, I think it is an open question whether it is
better to make two smaller changes spaced out over time versus a larger
change sooner.  I can see that the first strategy would be less disruptive
in the short term.  On the other hand, the installed base issue can only get
worse (hopefully).

Additionally, if we do it in two steps, I would think we wouldn't want to do
the second step to soon.  If we come out with two significantly different
standards to close together, our manager/tester/release/user folks will kill
us.

Presumably, the entire ebXML community will want to move to the newest
standard regardless of if it is two smaller steps or one big one.  Also, I
think we need to try and evaluate if using the same API would increase the
market acceptance of ebXML.  Speaking for IEC WG 16, since there is some
existing interest in using an ontology related API as a way to abstract from
the differences in registry access technologies, I would think that the use
of the RDF based API would increase market acceptance.  In this way, our
abstract registry API could be one in the same as our ebXML technology
profile and thus streamline our standards process.

John


-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
Sent: Friday, January 02, 2004 10:17 AM
To: John Gillerman
Cc: regrep@lists.oasis-open.org
Subject: Re: [regrep] RDF Data Access WG Charter


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