Re: Syntactic profile of RDFiCal?

We explored this option for probably over a year with XPackage ( 
http://www.xpackage.org/ ) in the Open eBook Forum (OEBF). We had really 
strong pullback in the OEBF against the use of RDF, on the theory that 
(1) we need to get book publishers to adopt OEB, (2) publishers can't 
understand RDF, and therefore (3) we have to use plain XML.

In the end, after the OEBF's plans for its next version stalled, I 
decided to take out the normative XML Schema version of XPackage 
altogether---it simply wasn't worth the effort. (The above logic forgot 
to figure in that publishers don't understand XML, either.) I left in an 
XML Schema version only for informative purposes.

* Creating an XSD version of XPackage in many ways negated the benefits 
of RDF.

* As you mention, if we want collections we *must* require an "ugly" 
rdf:parseType---it's not good enough to just make it a default attribute 
in a DTD.

* A pure XML version that is RDF-compatible still requires rules for 
processing rdf:about/rdf:resource---unless you intend to make *every* 
resource inline.

* Extensibility is basically gone, unless you introduce rules about how 
new XML elements can be added to the XML Schema, in ways that are RDF 
compatible. At this point, you're almost creating a separate framework 
that duplicates RDF.

* With an XSD or DTD version, the pure RDF version would be useless, as 
we would need to support the lowest common denominator. Otherwise, there 
would be both a pure XML version and a pure RDF version, in which case 
who cares if the XML version is RDF-compliant or not if there are two 
versions anyway?

I could go on and on. At first this sounds like a good idea, but the 
more you try to *work* with it, you realize that it's just a feeble 
attempt to placate those who claim they either (A) don't understand RDF, 
or (B) don't see the need for it. Either of those is a dubious reason to 
begin with, I've come to believe.

(Is Patrick Stickler on the list? Maybe he can share some of his 
opinions from helping me try to do this with XPackage.)

Cheers,

Garret Wilson
GlobalMentor, Inc.

Libby Miller wrote:

> 
> hi,
> 
> On the IETF calendar mailing list [1] they are currently talking about
> reviving Xcal, which was an XML DTD for iCalendar. I was wondering if
> we might want to think about a syntactic profile of RDFiCal, as the RSS
> 1.0 group did for RSS 1.0 with Leigh Dodd's Schematron schema [2], and
> as we have been doing in the foaf project, again with Leigh's help [3].
> 
> There are many disadvantages to doing this, the main one being that with
> all the RDF toolkits I have seen you can't control the output of the
> RDF, making a specific syntactic output difficult or awkward to create.
> 
> Additionally, I think we might have to rethink some of the syntax that
> is currently outputted by the iCalendar to RDF tools, as it often uses
> parseType="resource", which can make it difficult to use other
> namespaces with it, e.g.
> 
> http://swordfish.rdfweb.org/discovery/2003/09/foafcal/foaficaleg.rdf
> 
> shows an example of using foaf:Person with attendee. regardless of
> whether this is the right way to do it, if we use
> 
> <attendee rdf:parseType='Resource'>
> 
> in a syntactic profile, then there's no way we can get the foaf:Person
> tag in there. And that may not be too important for some people who
> focus on properties, but our foaf experience suggests that many people
> focus on objects when manipulating foaf files for display (and don't do
> any inference from the schema).
> 
> These caveats aside, I think an XML version of iCalendar that could be
> parsed and used by pure XML tools might be very well recieved, and
> we've done a lot of the hard work already. It'd be annoying to have
> another XML format in this space, although we could specify mappings to
> it if it was created.
> 
> What do you think?
> 
> Libby
> 
> 
> [1] http://www.imc.org/ietf-calendar/mail-archive/msg11885.html
> [2] http://www.ldodds.com/rss_validator/1.0/
> [3] http://rdfweb.org/pipermail/rdfweb-dev/2003-August/011890.html (see
> thread for useful discussion of some of the potential issues)

Received on Tuesday, 16 December 2003 12:03:04 UTC