RE: RDF semantics, access control description and timeranges

> -----Original Message-----
> From: www-rdf-calendar-request@w3.org [mailto:www-rdf-calendar-
> request@w3.org] On Behalf Of Graham Klyne
> Sent: Monday, December 16, 2002 7:59 AM
> To: Geoff Chappell
> Cc: 'www-rdf-calendar'
> Subject: RE: RDF semantics, access control description and timeranges
> 
> 
> At 10:17 AM 12/15/02 -0500, Geoff Chappell wrote:
> >Don't these problems only arise when you assume defaults based upon
the
> >absence of information? You really don't have the right to assume
that a
> >missing util:minute value means that the value is 0, do you?
> 
> Yes, I agree... (unless, perhaps, there is other information present
from
> which you could infer such a value.)
> 
> The difficulty then is that one has to decide up-front (i.e. when
defining
> a vocabulary) how much precision is to be required if splitting out
the
> different units as separate properties.  I think goes against many
> intuitive approaches to representing information.  

Yeah, it's seems similar in ways to the dublin core progressive
qualification/refinement practice - i.e. it seems like a natural and
intuitive way to go for humans, but doesn't seem to work so well in
practice for machines. The very feature that is appealing (in the dc
case) - the fuzziness of representation - makes constraining via strong
typing nearly impossible given tidy literals. As it stands today with
dc, you sometimes end up having to scrape the rdf to get what you need
(which seems rather contrary to the goals of the semantic web:) That
said, I think there are probably conventions that can preserve most of
the desired expressive freedom and yet still allow useful constraints --
but it will probably take us all a while to figure those out.

>E.g. you can't treat a
> VEVENT as a structure that can be extended/refined by adding yet more
> information:  each property you add should  in some sense increase the
> number of temporal situations thus described.  It did occur to me that
> this
> is an argument for sticking with the ISO-based string representation
of
> times.

That makes sense - you end up with sort of a local closed-world (i.e.
you're never going to get any more info that will change what that
literal looks like).

 
> #g
> 
> 
> 
> -------------------
> Graham Klyne


--geoff chappell

Received on Monday, 16 December 2002 10:14:17 UTC