W3C home > Mailing lists > Public > www-archive@w3.org > April 2006

Re: calendars in RDF and HTML: implicit/default values

From: Ben Adida <ben@mit.edu>
Date: Sat, 22 Apr 2006 13:49:20 -0400
Message-Id: <0DF011A1-65CB-4A2E-A137-67F48528EACC@mit.edu>
Cc: www-archive@w3.org, "Ralph R. Swick" <swick@csail.mit.edu>, Eric Miller <em@w3.org>
To: Dan Connolly <connolly@w3.org>


> One of the things that makes RDF/XML hard to deal with
> is that you can make up a vocabulary of terms, but
> you can't play any syntax tricks beyond that. You can't
> have defaults or syntactic shortcuts.

Right, being generic in the metadata you can express means that  
syntactic shortcuts can't be domain-specific. There may be ways to  
get generic syntactic shortcuts, though, which are probably good enough.

> In fromIcal.py, when we convert from .ics format
> to RDF, we fill in the defaults:
>     # fill in defaults
>     if not obj.has_key('interval'):
>         obj['interval'] = 1
> (it's actually in
> http://www.w3.org/2002/12/cal/icslex.py )

That seems less like a syntactic shortcut and more like a data- 
dependent rule. Can't this be expressed with OWL?

> I haven't implemented that in glean-hcal.xsl, but
> I have implemented things like "if the datetime
> value ends with a Z, use a different datatype".
> In fact, glean-hcal.py implements UTC offsets.
> So you can write
>   <abbr class="dtend" title="2006-04-25T09:50:00+0200">0950</abbr>
> and in the .rdf , it ends up as:
> <c:dtend
> r:datatype="http://www.w3.org/2001/ 
> XMLSchema#dateTime">2006-04-25T11:50:00Z</c:dtend>

I wonder if that can't also be dealt with using OWL... maybe not as  

That said, don't iCalendar-like programs support the Z timezones?  
Does this need to be dealt with in the parser?

> Another one is that <abbr class="geo" title="lat;long">...</>
> gets split into 2 properties.

Yeah, that's clearly domain-specific syntactic sugar. I can't see how  
RDFa would support this.

That said, domain-specific syntactic sugar really is bad for  
extensibility. If you have a domain-specific parser, than you can't  
add terms from other vocabularies to the same data.

> As far as I can tell, RDF/A is subject to all the constraints that
> RDF/XML is, in this respect. You can use any URI-terms you want
> (and bnodes and literals) but you can't play syntactic shortcut
> tricks the way you can with an XSLT transformation.

Yes, that's true.

> I thought we could sorta enhance RDF/A so that it just happens
> to include hCalendar and hCard syntax, but there's a remarkable
> amount of domain-specific stuff in the syntactic details.

which is also why those are very difficult to extend.

> I think it's feasible to find some middle ground between RDF/A
> and Embedded RDF for encoding RDF graphs in general, but I still
> think we're going to need specific syntactic support for important
> classes of information like calendars.

I think data-dependent defaults can be dealt with generically with  
OWL. I agree that domain-specific syntactic sugar cannot, but I think  
RDFa can do calendaring quite well without them....

What's the use case where this syntactic sugar is necessary and  
clearly superior to RDFa?

Received on Saturday, 22 April 2006 17:50:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:57 UTC