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

Dan,

> 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  
easily.

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?

-Ben

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