- From: Dan Connolly <connolly@w3.org>
- Date: Sat, 22 Apr 2006 16:02:39 -0500
- To: Ben Adida <ben@mit.edu>
- Cc: www-archive@w3.org, "Ralph R. Swick" <swick@csail.mit.edu>, Eric Miller <em@w3.org>
On Sat, 2006-04-22 at 13:49 -0400, Ben Adida wrote:
> 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?
No.
OWL can't express syntactic defaults.
> > 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.
No, OWL has nothing like that.
> That said, don't iCalendar-like programs support the Z timezones?
Yes; that's why it gets converted from +0200 to Z.
> Does this need to be dealt with in the parser?
Yes.
> > 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.
Well, you can mix any number of GRDDL transformations together
just fine.
> > 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'm not quite sure how extensibility is relevant to the
goal of getting calendar data in the semantic web via
an HTML dialect.
hCalendar + GRDDL has these properties:
- an HTML calendar idiom that people are willing to use
(though their willingness to use a profile attribute is unproven)
- a transformation hi of that idiom to .ics format for interop
with tools that grok that format.
- a transformation hr of that idiom to RDF (and back; hr is invertible)
and ir from .ics to RDF such that for any html document h,
ir(hi(h)) = hr(h)
The world of .ics tools has no real extensibility story, so I don't
expect the HTML calendar idiom to have one either.
GRDDL is plenty general, and hCalendar can be mixed with other
GRDDL idioms like embedded RDF, RDF/A, etc.
But I don't think we'll get hCalendar authors to switch to some
other syntax just because hCalendar isn't extensible enough; they don't
have an extensibility problem; or at least: they don't know they
have one.
> > 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.
No, I'm pretty sure they cannot. Only something with access
to the syntax of the page (like log:semantics/log:includes) can express
defaults.
> 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?
hCalendar times and geo, as demonstrated above.
My travel schedule and PDA data and all the EVDB data
and all the other hCalendar data in the world are use cases.
As to necessary... it's not that hCalendar _had_ to be designed
with syntactic suger; it's that, as a matter of historical fact,
it _was_ designed that way. As to superior... it doesn't have
to be superior, since it was there 1st. The 1st mover in a
tech marketplace has a huge advantage.
I'm not interested in trying to re-do everything that the
hCalendar folks have done by way of education and marketing
and tool deployment... we'd have to do _more_ in order to compete.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Saturday, 22 April 2006 21:02:46 UTC