Re: Why is RDF such a tough sell?

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