Explaining why we use RDF instead of just XML

Dan,
Meant to post to list, sorry.
Follows.

And correct subject.

Dan,
I'm unclear how great those constraints are if by this you mean
restrictions on the expressiveness of the language, what it is capable
of denoting.

<Dan said:
Those constraints take time to learn and understand and explain, and so
> adopting RDF isn't without its costs.</>

Perhaps you do mean constraints, that is specific requirements about how
certain things are expressed, but this actually adds to the usefulness
of the language, if not its expressiveness. I'm sure there is a trade
off but it seems to me that it would have to be identified as
a) greater intellectual effort is required to use RDF (maybe, though
this seems to me to be only a slight incremental increase in complexity
over XML schema which is already complex)
b) irrespective of the intellectual effort, rdf solutions must be well
chosen and can only encompass a slice of the problem domain. They are
highly specific and therefore it would be too costly (and unnecessary?)
to unfold them comprehensively out into full coverage. All of the given
examples are public examples of common usage. There is some sort of
universal element in them. I think we need to be able to identify the
cost benefits of far more restricted examples, examples that compete
with or augment business process flows would be one fruitful area to
explore. For instance what is the documentation and the business flows
entailed in a domestic building insurance claim? Here, without knowing
specifics, it seems credible to identify both document (and therefore
business) flows as well as the possibility of embedded document logic.
In using rdf we should be free from concerns about the range of our
data, but what comes into focus is the complexity of the domain. This,
in turn, points to a couple of ways of evaluating benefits. Where the
range is extensive an effort in resolving a complex domain should be
worthwhile. (But perhaps the domain should be sufficiently complex for
this to be true?) However, a complex domain with a restricted range may
be worth resolving in a way simply because it is complex and this may
yield unanticipated beneficial results or, even, side effects. This
would be an improvement in quality. To take my example of an insurance
claim the parties involved range through Insurer, Owner, Loss_adjuster,
Surveyor, Engineer, Builder and each of these has particular designate
roles significant in assessing particular actions. For instance the
builder might have Project_manager and Foreman while Owner might also
need to be broken down into Owner_ocuper and Householder. As can be seen
these are only very course grained distinctions so far. In this case
stage payments made by the Loss_adjuster might be controlled by
automatic inspection of submitted documents to ensure that different
sections exist, have been filled in and have themselves been evaluated
by the loss adjuster. The insurer, concerned about value for money,
might run external checks over those documents to ensure that there
isn't a consistently under performing builder in a particular area of
work (either specialist, geographic or time - such as busy periods).
That might be a double check on the loss adjuster. Although this type of
thing is implemented without rdf, clearly rdf has several advantages.
First of all there would be two specialist applications talking to each
other, one with the loss adjuster, the other with the insurer. That is
OK, but others are excluded from the loop, whereas it would be trivial
to design a system whereby xml (and therefore rdf) documents could be
submitted by all parties. The other point would be that this would then
allow the insurer, or any other party, the ability to track all
documents or document sections. The insurer could then question why a
certain document has been filled out by the builder in a certain way.
This built in ability would be very valuable in some circumstances.
<Aside> Stick in some calendaring and we begin to get a really useful
application. Jarvis eat your heart out. For those who don't know Jarvis
are a major contractor to British Rail and were implicated in a recent
train disaster. One of the issues with them is that they sometimes seem
not to know where, when and who their workers are. They are forming part
of a consortium bidding for major NHS contracts. </Aside> This example
should be useful to explain why use rdf rather than xml. It may be that
others on the list are a bit reticent to give real examples because of
the intellectual effort (read time) associated with working them up? I
did mention that I think efforts would have to be well chosen and
restricted to part of the problem domain only. I'm not sure how that
fits with this example as it seems to me that once something like this
was implemented it would encourage further, wider, implementations.
However, there are some very complex domains where the number of factors
is just too great and it might be counter productive to do anything
apart from taking a slice through it as a sort of least path of
resistance impingement. One of the factors to consider here is the
degree of autonomy between identified parties. It the example I have
given there is a high degree of autonomy. My hunch is this is a factor
to look out for when modelling.

Adam


Adam Saltiel
Lecturer Software Engineering
University of Greenwich
School of Computing and Mathematical Science
Greenwich
London

Proprietor Configuration Science

> -----Original Message-----
> From: www-rdf-interest-request@w3.org [mailto:www-rdf-interest-
> request@w3.org] On Behalf Of Dan Brickley
>
>
> RDF IG, (copying SWAD-Europe list)
>
> I've just written a few comments in a weblog,
> http://www.pmbrowser.info/hublog/archives/000258.html that I thought
> I'd archive here too, see if they make sense to folks. I was trying to

> explain a bit about why RDF might make sense for someone considering
> the use of XML for a vocabulary. I think maye I just restated what
> Danny said there at greater length...
>
> [[
> One way to think about this: the Resource Description Framework (RDF)
> is a family of XML applications who agree to make a certain tradeoff
> for the sake of cross-compatibility. In exchange for accepting a
> number of constraints on the way they use XML to write down claims
> about the world, they gain the ability to have their data freely mixed

> with that of other RDF applications.

> Since many descriptive problems are inter-related, this is an
> attractive offer, even if the XML syntax is a little daunting.
> MusicBrainz can focus on describing music, RSS 1.0 on describing news
> channels, FOAF on describing people, Dublin Core on describing
> documents, RdfGeo on places and maps, RdfCal
on
> describing events and meetings, Wordnet on classifying things using
nouns,
> ChefMoz on restaurants, and so on.
>
> Yet because they all bought into the RDF framework, any RDF document
> can draw on any of these 'vocabularies'. So an RSS feed could contain
> markup describing the people and places and music associated with a
> concert; a calendar entry
> could contain information about it's location and expected attendees,
a
> restaurant review could use FOAF to describe the reviewer, or a FOAF
file
> could use Dublin Core to describe the documents written by its author,
as
> well as homepages and other information about those authors.
>
> So, for any particular application, you could do it in standalone XML.

> RDF is designed for areas where there is a likely pay-off from
> overlaps and data merging, ie. the messy world we live in where things

> aren't so easily parceled up into discrete jobs.
>
> But it is a tradeoff. Adopting RDF means that you just can't make up
> your XML tagging structure at random, but you have to live by the
> 'encoding' rules expected of all RDF applications. This is so that
> software written this year can have some hope of doing useful
> things with vocabularies invented next year: an unpredictable 'tag
soup'
> of arbitrary mixed XML is hard to process. RDF imposes constraints so
that
> all RDF-flavoured XML is in broadly the same style (for example,
ordering
> of tags is usually insignificant to what those tags tell the world).
> Those constraints take time to learn and understand and explain, and
so
> adopting RDF isn't without its costs.
>
> And so the more of us who use RDF, the happier the cost/benefit
> tradeoff gets, since using RDF brings us into a larger and larger
> family of inter-mixable data.
>
> Does this make any sense?
> ]]


> -----Original Message-----
> From: www-rdf-interest-request@w3.org [mailto:www-rdf-interest-
> request@w3.org] On Behalf Of Dan Brickley
> Sent: 25 June 2003 15:34
> To: Richard H. McCullough
> Cc: www-rdf-interest at W3C
> Subject: Re: time-varying properties
>
>
> * Richard H. McCullough <rhm@cdepot.net> [2003-06-25 07:13-0700]
> >
> > Given the triples
> > (1)    John  height  60
> > (2)    John  height  70
> > can RDF say that (2) replaces (1) -- as opposed to
> > both (2) and (1) being true?
> >
> > Can OWL say that (2) replaces (1)?
>
> Neither the RDF, RDFS or OWL specs really goes far into this
> fascinating and rather tricky area. I do hope it'll get some attention

> in future standardisation work, once we've all got a better handle on
the
> problem.
>
> In my FOAF experiments, I've often claimed that foaf:mbox is a
> 'static' unambiguous property, in that a given property/value pair
> (eg, foaf:mbox=mailto:danbri@w3.org) should never be true of varying
> objects over time. That's tough to formalise given
our
> current ontology languages...
>
> Dan
> formalise given current current

Received on Wednesday, 25 June 2003 18:53:12 UTC