OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Semantic Web permathread, iteration n+1 (was Re: [xml-dev]

[ 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:
> 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 -


You can change it just a bit like this to get legal rdf -

     <prop1 rdf:parseType='Resource'>
        <prop2 .../>
        <prop3 .../>

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?


Tom P


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS