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
