[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
<John Gillerman>The question is can the entire registry (including the semantic content addition) be seen as an ontology and thus accessible via an RDF based API. This is clearly more disruptive to the ebXML community, but is the disruption worth it to get along the path of unification of the semantic web community with the ebXML community.</John Gillerman> John, I think that it is a question of "has-a versus is-a." The ebXML Registry has an ontology but it is a registry. If the Knowledge model is explicitly defined (i.e., like in an ontology) then any API or representation (e.g., RDF, RDF-Rule, OWL, OWL DL, OWL Full) can be supported. IMHO: You allude to one of the major problems that we will face. How do we align object oriented issues with ontology oriented issues? What is more important the knowledge or the methods that act upon that knowledge? Objected Oriented analysis is most concerned with the methods. I think that you have to clearly separate the two issues or the Object Oriented and Semantic/Knowledge Oriented communities will be talking past each other. My proposal is that the Object Oriented issues be covered in the RIM/RS and Semantic/Knowledge Oriented issues will be covered in the Registry Knowledge Model. I just think we gain more interoperability benefits talking about ebXML Registry compatibility and how to access it versus only how to access it. RDF API support could be a non-issue by the time the standard is worked but compatibility will always be an issue. 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: John Gillerman [mailto:john.gillerman@sisconet.com] Sent: Monday, January 05, 2004 12:10 PM To: regrep@lists.oasis-open.org Subject: RE: [regrep] [Q] RDF API versus creating an ebXML Registry Knowledge Model Zachary, I think one still wants an single API to access the ontology and the rest of the registry. Otherwise interoperability between vendors is limited. The question seems to be what API. The default choice is clearly the existing ebXML API since it is well supported. The question is can the entire registry (including the semantic content addition) be seen as an ontology and thus accessible via an RDF based API. This is clearly more disruptive to the ebXML community, but is the disruption worth it to get along the path of unification of the semantic web community with the ebXML community. I think that one could suggest that these two communities would be stronger working together than apart - but at what cost. This goes back to the "divided we fall" issue aka the world of only WinFS (instead of also RDF) and UDDI (instead of also ebXML registry). John -----Original Message----- From: Zachary Alexander [mailto:zack2003@ebtdesign.com] Sent: Monday, January 05, 2004 11:33 AM To: regrep@lists.oasis-open.org 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. 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]