At 06:09 PM 12/9/02 -0600, pat hayes wrote:
>>At 10:36 AM 12/9/02 -0600, pat hayes wrote:
>>>Well, yes, but rdf:value *is* contextual, but at least this keeps it in
>>>bounds. I'd prefer to abandon it, but that's apparently not an option.
>>
>>Er, yes. In the past few days, I've come across a few instances of its
>>use in RDF schedule data. Some of which, I think, doesn't conform with
>>your proposed "abbreviated form" approach; e.g.
>
>Well, if I understand these examples, it seems to me that they do, at
>least plausibly. I gather that the value of the rdf:value triples here is
>a representation of the 'full' value, and that the others are 'pieces' of
>it broken out for access via RDF reasoning, is that correct? Because if
>so, that fits perfectly: in this case presumably it would, or at least
>could, be appropriate to write that 'full' value as the value of the
>DTSTART property of the event, no?
OK, if you say so (and I don't mean that facetiously).
The reason I expressed doubt was that the rdf:value value did not match the
value of some other property, which I had the idea was part of your approach.
As for what the example *means*, I have little more information than you
;-) However, your explanation concurs with my understanding.
>>[[
>><VEVENT>
>><!--- snipped -->
>><DTSTART>
>>
>><DATE-TIME>
>><TZID rdf:resource="#US-Eastern"/>
>><rdf:value>20010226T090000</rdf:value>
>><util:hour>09</util:hour>
>><util:minute>00</util:minute>
>></DATE-TIME>
>></DTSTART>
>>
>><DTEND>
>><DATE-TIME>
>><TZID rdf:resource="#US-Eastern"/>
>><rdf:value>20010227T173000</rdf:value>
>><util:hour>17</util:hour>
>><util:minute>30</util:minute>
>></DATE-TIME>
>></DTEND>
>></VEVENT>
>>]]
>>-- http://www.ilrt.bristol.ac.uk/discovery/2001/06/content/rdf_meeting.rdf
>>
>>This is just an example picked at random. I've noticed this pattern a
>>couple of times in iCalendar/RDF data.
>
>Look, there is a more general issue here. Our charter asks us to make the
>RDF M&S clear. That thing that we were supposed to clarify has spawned
>this monstrosity BY BEING UNCLEAR about what rdf:value is supposed to mean
>or to be appropriately used for. The result, that existing code use it for
>all kinds of not-mutually-compatible things, is the PROBLEM that we are
>supposed to be solving, seems to me, not the state of affairs that we are
>supposed to preserve by avoiding anything that might violate some use
>case. If the existing use cases, taken as a whole, are confused, then one
>or more of them have GOT to change, or else we just declare that confusion
>reigns and we are not going to do anything about it. Which, to return to
>my first point, seems to me to be a clear violation of our charter. If
>confusion were supposed to reign, there would have been no need to form
>this WG in the first place.
Yes, no argument from me...
>So I think that we should say something that makes an intended use case
>for rdf:value reasonably clear, and then say that this is what rdf:value
>is supposed to mean. We should try to capture as many use cases as we can,
>of course, but if we can't get them all, we should not just give up. Im
>not sure what the above pattern is supposed to mean, to tell you the
>truth, but if it can't be interpreted in the way I suggest, then
>iCalendar/RDF will have to invent a new property: tough.
... if your explanation covers this case, then I think there's no more to
say, and I'm pleased that the data I found is not an impediment to your
proposal to describe the intended meaning of rdf:value.
#g
-------------------
Graham Klyne
<GK@NineByNine.org>