[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
<Quote>
then any API or representation (e.g., RDF, RDF-Rule, OWL, OWL DL, OWL
Full) can be supported.
</Quote>
Are we mixing terms here? Seems like we're equating API with
representation, when perhaps we should not...
Joe
Zachary Alexander wrote:
>
> <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.
>
> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]