- From: <MDaconta@aol.com>
- Date: Mon, 24 Jun 2002 15:54:42 EDT
- To: jtauber@jtauber.com, www-rdf-interest@w3.org
- Message-ID: <7d.29373bd0.2a48d302@aol.com>
Hi James, While I understand your distinction, I don't see how it helps in terms of practical implementation strategy. I would summarize your argument as "RDF as ontology language" which is "deeper" than "XML for data interoperability". BUT, doesn't this then assume that businesses should wait until ontology languages and vertical ontologies are nailed down before RDF is practical? Secondly, what is the business justification for using an ontology instead of just fixing the definition? Most b2b is with known partners that have legal contracts defining the relationship -- it's faster to just agree on definitions than agree on ontologies of objects. And then even if you argue successfully for the "richer is better" approach, it still seems to require waiting on the Ontology languages to be finished. In that case, why bother with something like RSS and Dublin Core as RDF now? More below... In a message dated 6/24/02 11:19:05 AM, jtauber@jtauber.com writes: > XML schema languages are principally about constraining the surface syntax > of a class of XML documents. > > Having worked on standards for electronic mortgages this was definitely not true in that effort. The first product was a logical data dictionary. Thus I look at this as XML Schema simply using a "fixed context" whereas RDF will be built up from basic axioms in a non-contextual way (and hopefully more universal). However, it is difficult to argue that a fixed context is "worse that" a dynamically derived context. In terms of ROI, if a fixed context is faster to build that may be the way to go. This seems to pull us back to RDF only for the semantic web. While I can intuitively see the benefits of ontologies ... they still scare the bejesus out of average developers and managers and don't have a proven ROI. <BLOCKQUOTE CITE STYLE="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px" TYPE> RDF is principally about expressing the properties of and relationships > between objects (and an RDF *schema* about constraining those properties > and > relationships). > > Consider > > > James > > > The XML view of this is "element of name 'Person' with child element of > name > 'Name' with character data 'James'". An XML schema can say things like "a > 'Person' element can contain a 'Name' element". > > Again, see where you are going but don't agree. I could just as easily say that an element as container provides an implicit "HAS-A" relationship. Then the only difference would be that RDF makes relationships specific but XML Schema has some simple built-in relationships that work real good for modeling object characteristics. > The RDF view of this is "there is a class of objects designated 'Person' and > this particular person has a 'Name' of 'James'." An RDF schema can say > things like "objects of the type 'Person' can have 'Name's". > > So RDF is considerably more perspicuous in modelling data. 'Name' is a > valid > property of a 'Person' is generally more insightful than 'Name' is a valid > sub-element of 'Person'. In a sense RDF is more fundamental than XML as it > about the nature of the data, not just some particular serialization of it. > Of course, any collection of objects and their relationships can be > expressed in XML but you have to then decide how the relationships and > properties are going to map to elements and attributes (and vice versa on > the other end). > > In that sense, would you say that RDF as ontology language would then be orthogonal to XML Schemas ... in other words, potentially having your RDF ontology refer to (or map to) the elements and attributes of an XML Schema? While that would avoid the competition, you would then also not really have RDF instance documents - just ontologies? Is this a correct characterization of your above argument? Thanks for the feedback, - Mike > > > ------------------------------- > Michael C. Daconta > Director, Web and Technology Services > www.mcbrad.com
Received on Monday, 24 June 2002 15:55:46 UTC