Any option for a RDF/XML subset?

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hi John,

many thanks for sharing these very interesting information about RDF/XML 
and alternatives!

Personally I doubt we are able to use to a different RDF XML 
serialization as RDF/XML, which is currently the W3C standard for XML 
serialization and which still seems to fit our Office Metadata 
requirements, although causes problem with XML processing.

Considering the time we have left for the complete proposal, I would 
rather consider for this version the solution to restrict the included 
RDF/XML in the package to a subset of the syntax, as provoking a 
normalization and upgrade to a alternative RDF XML metadata standard, 
when it becomes available as a standard.
Such a normalization could be achieved by a transformation that have to 
be written once for ODF applications and might help all XML processing, 
therefore seems wort to be considered

Do you have a proposal for a RDF/XML subset?

PS:
Just wanted to reply now to your mail, as it seems that it had not reach 
everyone on the mailing list.
This discussion has currently not the highest priority to me, I first 
want to bring out a proposal draft.

Regards,
Svante


John C Barstow wrote:
> I'm going to raise my head above water here to mention that the XPath
> problem is *precisely* why the TriX format[1] was invented.
>
> One of the core requirements was that the format be amenable to
> processing with XPath and XSLT, one which I think it meets admirably
> (incidentally supporting one of my pet features, named graphs).
>
> Bruce may be unaware of this, but one of the reasons RDF stumbled so
> badly when first introduced was the RDF/XML syntax. Certainly Dave
> Beckett et al. have eliminated some of the worst problems, but it really
> was the emergence of N3 as a decent serialization format that kept RDF
> from dying completely.
>
> The fact of the matter is that when working with XML, it is inevitable
> (at least in the current era) that any transformation of the document
> will be attempted with XSLT. It's the tool of choice for most publishing
> pipelines, and OpenDocument needs to fit into those pipelines, alongside
> XML-FO and DocBook (for example).
>
> With TriX, at least, it's possible to author metadata using qnames
> (natural for hand-authored documents), and trivial to convert to full
> URIs using XSLT.
>
> <xsl:template match="trix:qname">
>   <uri>
>   <xsl:value-of
>         select="namespace::*[
>       local-name()=substring-before(text(),’:’)
>                 ]"/>
>   <xsl:value-of select="substring-after(text(),’:’)"/>
>   </uri>
> </xsl:template>
>
>
> Honestly, I've seen many attempts to fix RDF/XML, and it's my contention
> that it's fundamentally broken. It doesn't work as XML because it is
> inherently unfriendly to XPath, and it doesn't work as RDF because it's
> too unwieldy. It *scares* people who are trying to learn the RDF model
> because it hides the simplicity of the underlying model with a
> convoluted syntax.
>
> My advice is to at least learn from the past analyses (see sections 3
> and 4 of the aforementioned paper for example) and adopt an XML-friendly
> syntax - that will lessen the opposition from the wider working group
> (who are all clearly comfortable with existing XML best practices) and
> avoid some of thornier postponed issues [2] with the syntax.
>
> In particular, "The RDF/XML syntax can't represent an an arbritary graph
> structure" is likely to be bit of a showstopper in actual
> implementation, as it's not hard to generate metadata that triggers this
> issue.
>   
Isnt' Yes, but the usage of rdf:i
> [1] http://www.hpl.hp.com/techreports/2003/HPL-2003-268.html
> [2] http://www.w3.org/2000/03/rdf-tracking/
>
>