[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] [Q] RDF API versus creating an ebXML Registry Knowledge Model
<Matt>I like purpose driven APIs, but I am not so wild about purpose
driven
data models when we are dealing with registry technologies. A good
metadata registry data model should be flexible enough to support nearly
any metadata application, and if the API doesn't "feel right", make it
feel right with an API adapter.</Matt>
IMHO: An ebXML Registry Knowledge Model would be a lot like a metadata
registry data model. Instead of modeling the Registry data elements it
would model the Registry concepts. An ontology then could be built to
translate between the Registry Knowledge Model and any new purpose
driven APIs. An ebXML Registry that is Semantic/Knowledge aware would
not care about APIs because ontologies would be used to formally handle
interoperability.
BTW: This discussion is relevant only to the Registry 4.0 Semantic
Content work.
Zachary Alexander
The IT Investment Architect
ebTDesign LLC, (703) 283-4325
http://www.ebTDesign.com
http://www.p2pspeaker.com
http://www.p2peconomy.com
-----Original Message-----
From: Matthew MacKenzie [mailto:mattm@adobe.com]
Sent: Monday, January 05, 2004 10:42 AM
To: regrep@lists.oasis-open.org
Subject: RE: [regrep] [Q] RDF API versus creating an ebXML Registry
Knowledge Model
Zachary,
To clarify, I don't think that ebXML Registry itself should define any
new APIs. We should have one, solid and well supported API. If third
parties wish to make purpose specific APIs, I think that is great as
long as they act as adapters to the ebXML Registry API. I like to
compare ebR API to JDBC, and purpose specific APIs as DAOs using JDBC.
DAO/JDBC
findEmployeeID(name) --> query("select ID from employees where
name='name'")
Purpose Specific API/ebR API
getCompanyNames() --> <AdhocQueryRequest>...</AdhocQueryRequest>
I like purpose driven APIs, but I am not so wild about purpose driven
data models when we are dealing with registry technologies. A good
metadata registry data model should be flexible enough to support nearly
any metadata application, and if the API doesn't "feel right", make it
feel right with an API adapter.
-Matt
-----Original Message-----
From: Zachary Alexander [mailto:zack2003@ebtdesign.com]
Sent: Monday, January 05, 2004 11:25 AM
To: regrep@lists.oasis-open.org
Subject: RE: [regrep] [Q] RDF API versus creating an ebXML Registry
Knowledge Model
<Matthew MacKenzie>I agree 100% that having a single API is critically
important. There already is a perception that "ebXML" is too
complicated for the average developer, giving rise to purpose-driven
registries such as UDDI. Please don't add more APIs! </Matthew
MacKenzie>
Matthew, I don't think that purpose-driven ebXML Registries are
necessarily a bad thing. I have never liked UDDI Registries. I would
think that you want people extend the solutions that the ebXML Registry
used to satisfy. I remember the first time I used a LDAP database to
serve dynamic content. It felt "wrong." The LDAP database was written
originally as a means to store user passwords and group privileges. But
LDAP databases had quicker read properties than Relational Databases at
that time.
<Matthew MacKenzie>If ebReg is to allow formats like RDF within a
SubmitObjectsRequest, I would support adding a new type of request, call
it CapabilitiesRequest, where a registry could list the types of XML
data it can accept and where. I think this would greatly benefit
interoperability as this type of functionality is added. </Matthew
MacKenzie>
I think that the bigger question becomes should the ebXML Registry
standard reflect the difference between an Object Oriented "Class" and
Ontology Oriented "Concept." Should we be talking about Description
Logics and OWL DL support? Do we run into problems with RDF support
when RDF-Rules standard is finished?
Zachary Alexander
The IT Investment Architect
ebTDesign LLC, (703) 283-4325
http://www.ebTDesign.com
http://www.p2pspeaker.com
http://www.p2peconomy.com
-----Original Message-----
From: Matthew MacKenzie [mailto:mattm@adobe.com]
Sent: Monday, January 05, 2004 8:42 AM
To: regrep@lists.oasis-open.org
Subject: RE: [regrep] [Q] RDF API versus creating an ebXML Registry
Knowledge Model
Farrukh,
I agree 100% that having a single API is critically important. There
already is a perception that "ebXML" is too complicated for the average
developer, giving rise to purpose-driven registries such as UDDI.
Please don't add more APIs!
If ebReg is to allow formats like RDF within a SubmitObjectsRequest, I
would support adding a new type of request, call it CapabilitiesRequest,
where a registry could list the types of XML data it can accept and
where. I think this would greatly benefit interoperability as this type
of functionality is added.
Regards,
Matthew MacKenzie
Senior Architect
Adobe Systems
mattm@adobe.com
-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
Sent: Monday, January 05, 2004 9:31 AM
To: regrep@lists.oasis-open.org
Subject: Re: [regrep] [Q] RDF API versus creating an ebXML Registry
Knowledge Model
Zachary Alexander wrote:
> All,
>
> Would it be better to create an ebXML Knowledge Model? This document
> would outline the Semantic/Knowledge Model and facilitate
> interoperability. The RDF API solution seems like a bolt-on solution
> to me that doesn't solve the problem of how to make the registry
> Semantic/Knowledge aware.
>
In my strawdog thinking I am assuming that our API would remain largely
unchanged and as defined by ebRS. What would be different is that in
addition to RegistryObjects one can submit RDF and OWL content within a
SubmitObjectsRequest. The query API is where there is likely to be
impact. The minimal impact is to enhance existing query syntax in order
express ontology based queries. A more significant impact to query may
be driven the RDF Data Access WG requirements.
The information model would be largely unchanged in phase 1 other than
the addition of RDF and OWL model elements.
> Should the question of API's be an implementer's problem or a Registry
> problem?
>
I believe interoperability requires a single standard API to the
registry.
> If we have a Semantic/Knowledge Model that shows how knowledge will be
> represented natively in the Registry then it is up to implementers too
> translate any API to the Registry Knowledge Model.
>
Again I believe it is important to have a single standard API to the
registry that also supports new RDF, OWL related features.
Maybe what you are saying is that we do not need to provide APIs to
manipulate RDF and OWL content and leave that to implementations. If so,
I tend to agree with you.
> One of the problems is that RDF support alone won't support OWL.
>
+1
> There will have to be a separate API(s) to support OWL and/or OWL
> Lite, OWL DL, OWL Full. I have also seen papers that talk about using
> "Topic Maps" to represent Semantic/Knowledge. Seems like five API's
> right out of the gate.
>
My sense of API is that it is fairly generic. It is basically what we
have today embellished to allow Ontology aware queries and use of
Ontologies in Classification of objects.
BTW reminder that the SCM SC vote closes today so please make sure you
cast your vote. Thanks.
--
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_workgr
oup.php.
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_workgr
oup.php.
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_workgr
oup.php.
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_workgr
oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]