[
Lists Home |
Date Index |
Thread Index
]
I'm late to the thread, hope I'm not repeating this approach ("Use
RDF, Spend More Time With Your Loved Ones"):
> GOAL
>
> My goal is for us (the xml-dev group) to collectively define a systematic
> approach to using simple XML vocabularies to implement large (complex)
> systems.
The "simple" there could be more precise in terms of requirements, but
ok, taking the hand-waving interpretation...
> Imagine that a large system requires an Invoice XML vocabulary for a Book
> purchase.
Step 1: check that no existing vocabularies cover the domain(s). If
they do, reuse, job done. (If necessary, using individual terms from
different vocabs - XML namespaces and the RDF/XML interpretation can
maintain the structure).
A good place to look:
http://www.schemaweb.info
There are a few that could help with this example, but assuming none
were found...
> The approach that Len suggested was to use a "metadata framework" which ties
> together the simple vocabularies.
Sure. But again, reuse is good. There is a fairly sophisticated
Resource Description Framework available.
> In the above Invoice example tags that are specific to postal addresses and
> books were used. A disadvantage is that many domain-specific simple
> vocabularies must be created.
Why is this a disadvantage? If a certain level of granularity is
needed, many different names will be needed whatever you do (though
this can be minimised by using structural relationships between the
terms).
> Peter's approach is to provide a "generic set of tags", coupled with a rich
> set of ways to relate the generic tags.
The basic idea is good, but there's no need to invent a new system.
With RDF you have a generic construct, the resource, which can be
specialised and related through properties. The subclass/subproperty
capabilities etc of RDFS allow moderately sophisticated schema-level
relationships, if you need more sophistication, use OWL.
Next step, basic identify the key entities (resources and literals)
and relationships and where possible their types. You could do this in
a high-falootin' ontological stylee, now or later, but going for a
simple XML version you get very quickly to the next step:
RDF/XML syntax issues. Curse or blessing. The original version you
gave was very close to striped RDF/XML, but the relationship between
the invoice and the items wasn't explicit. I'm not sure what you had
in mind for the id attributes, here I've used abbreviated URIrefs. So
here's the prototype RDF-constructed instance doc:
<Invoice xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns="http://example.org/books/"; rdf:ID="INV0001">
<useAddress>
<PostalAddress rdf:ID="RLC">
<Addressee>Roger L. Costello</Addressee>
<Street>38 Boylston St.</Street>
<City>Boston</City>
<State>MA</State>
<Zipcode>01320</Zipcode>
</PostalAddress>
</useAddress>
<product>
<Book rdf:ID="Bach">
<Title>Illusions</Title>
<Author>Richard Bach</Author>
<Date>1977</Date>
<ISBN>0-440-34319-4</ISBN>
<Publisher>Dell Publishing Co.</Publisher>
</Book>
</product>
</Invoice>
Even if you don't use this vocabulary as RDF, only ever treating it as
XML, the entity/relationship analysis process should at least have led
to a fairly clean format.
Another advantage is that you can now use off the-shelf tools for
storage/processing/query through the RDF model. What's more your data
will be interoperable with any other company that has used RDF, either
directly if you've both reused existing vocabs or indirectly through
mapping+inference (it's indirect, but the techniques are
straightforward and tools again available off-the-shelf).
The cost of using this approach? Minor syntax adjustments - the
introduction of a namespace, restructuring to make a relationship in
the data explicit. The benefit - more quality time with your cat.
Cheers,
Danny.
--
http://dannyayers.com
|
