[
Lists Home |
Date Index |
Thread Index
]
Joshua Allen wrote:
> No, what is meant by "striping" is that you can alternate between having
> element map to a property name vs. map to an item name. For example:
[snip]
> So, basically, you have to look at the context to determine whether an
> element represents a property name or an object name. The XML
> alternates between property name and object name based on depth, so it's
> kindof like "stripes".
>
>>Why is there distaste for striping, as you mentioned?
>
> Some people dislike it, because it's not obvious when looking at a chunk
> of XML whether a specific element is being used an item name, or as a
> property name. An item can also be used as a property value, so that is
> not such a problem. The real issue is that property *names* are not
> interchangable semantically with item names or property values, so you
> have to treat them differently in code. So it can be confusing when
> they appear to be used interchangably in the XML, and it can seem rather
> arbitrary that you have you have to pay attention to the depth within
> the document to decide whether something is a (p) or an (s or o).
> Anyway, it's not such a terrible thing. Some people think it's more
> usable.
>
Right, an arbitrary piece of xml does not carry enough information to
let you automatically distinguish between elements that represent things
and those that represent properties. A person generally has to work
that out. But when you do have a properly striped format, it can be
easy to turn into rdf (it's usually just about there as is).
Probably the most common case that causes striping to break down is when
an apparent property contains more than one child elements. This is
impossible with rdf, since one property can only have one object.
rdf:parseType='Resource' to such an element, which causes the object to
become a bnode, with the several child elements hanging off that. E.g.
given this typical bit of xml -
<noun1>
<verb1>
<value1/>
<value2/>
</verb>
</noun>
You can change it just a bit like this to get legal rdf -
<noun1>
<prop1 rdf:parseType='Resource'>
<prop2 .../>
<prop3 .../>
</verb>
</noun>
If you add namespaces and feed this into the W3C rdf validator (you can
configure it not to require an rdf:RDF wrapper), you will see that the
processor creates a new bnode, and that prop3 and prop3 become
properties of the bnode.
Oh, yes, you sometimes have to add an rdf:resource attribute of the
occasional element, too.
So with just a bit of adjustment, many ordinary xml files can become
legal rdf as well. This approach lets you work with the files using
ordinary xml tools, like xslt, and also to apply rdf tools and reasoners
if and when you want to do that.
This approach can be an easy way to slip rdf in by the back door, too,
because it is hardly different from "ordinary" rdf. If you have to
create a new format anyway, why not make it rdf-compatible anyway, if
the additional cost is so low as it is using this approach?
Cheers,
Tom P
|
