Re: Data stuff

Evan Wallace wrote:
>
> Deborah L. McGuinness wrote:
>>
>> Bijan Parsia wrote:
>>
>>>
>>> The owl working group will be discussing datatypes and n-ary data 
>>> predicates today at the f2f.
>>>
>>> See:
>>>    http://www.w3.org/2007/OWL/meeting/2008-07-16#Normative_datatypes
>>>    http://www.w3.org/2007/OWL/wiki/N-ary_Data_predicate_use_case
>>>    http://www.w3.org/2007/OWL/wiki/N-ary_Data_predicate_proposal
>>>
>>> If you have use cases, strong feelings, questions, etc. now is a 
>>> good time to voice them.
>>>
>>> Cheers,
>>> Bijan.
>>>
>>>
>> thx for the reminder.
>> two points arise for me:
>> 1 - i do not see datetime on the agenda - is it embedded in something 
>> i missed or are we holding off because it needs more discussion
>
> It is there http://www.w3.org/2007/OWL/wiki/F2F3_Agenda as
> "Date and time types" just before N-ary within the Datatypes topic.
> We are now on break.
whops - thx.  missed that.
>
>> 2 - if datetime is discussed, i would have trouble living with a 
>> solution that forced me to represent datetime as structured owl 
>> objects rather than xsd:datetime or something like a more granular 
>> xsd:datetime 
>
> My write-up of the current proposal uses xsd:dateTime.  There will be
> some hacks required for dealing with things that differ from full 
> xsd:dateTime with a timezone component.
is there a link to this that i also missed?
>
>> because of the sheer volume of datetime data my applications have.
>> exemplar use case for datetime is:
>> 2a. retrieve data with a start time of yymmdd for a duration of 10 
>> days  (optional time zone, default is ut, optional hours, minutes, 
>> seconds)
>
> I strongly dislike quietly defaulting to UTC.  Tools should at least
> complain when they do this.  IMHO it would be better to just disallow
> this and expect tools to either gag on it or interact with the user to
> repair it.
that is application level so i believe beyond the scope of the 
discussion to some extent....
but this is a good point if we have optional granularity, if owl expects 
any default to be implied.
i agree with bijan that our specifications would not want to enforce a 
default.
when i said the default is utc - that was an application level default 
and not a request for a language specified default.
i actully hate things that force a default for me since it is possible 
that i just do not know more information than i am putting in at any 
particular point in time.
>
>> 3 - i notice that comparison is embedded in the proposal.  as long as 
>> i get something that lets me do comparisons and numerical ranges i 
>> can make due. exemplar use cases are:
>> 3a. atmosphere above xxx feet and below yyy feet
>> 3b. high geomagnetic activity = something with a kp index above 7
>>
>>
>
> Currently spec'd datatype restrictions support this don't they?
yes - i agree .
i am just supporting the current proposal for this point while pointing 
out that this is my major need from this issue.
>
> -Evan
>
>
>

Received on Monday, 28 July 2008 15:08:50 UTC