W3C home > Mailing lists > Public > public-owl-wg@w3.org > June 2008

Re: ISSUE-126 (Revisit Datatypes): The list of normative datatypes should be revisited

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 19 Jun 2008 13:53:18 +0100
Message-Id: <77E5E4D8-FD99-40CC-B138-662D1E853F6D@cs.man.ac.uk>
Cc: Boris Motik <boris.motik@comlab.ox.ac.uk>, 'OWL Working Group WG' <public-owl-wg@w3.org>
To: Ivan Herman <ivan@w3.org>

On 19 Jun 2008, at 13:43, Ivan Herman wrote:

> Hi Boris,
>
> in case this was discussed on the call, I am sorry because I was  
> not there... I would like to understand...
>
> Boris Motik wrote:
>> Hello,
>> So here is a proposal for resolving this issue.
>> 1. We exclude xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear,  
>> xsd:gMonthDay, xsd:gDay, xsd:gMonth, and xsd:base64Binary from the  
>> list
>> of supported datatypes. Note that this doesn't preclude people  
>> from implementing them (if they can figure out how to do this).
> > 2. We define xsd:anyURI to be a subset of xsd:string.
> >
>
> Can you elaborate what this means? For example, xsd:date is used  
> quite a lot in RDF data using vocabularies like Dublin Core,  
> Bibliography Ontology, or others. What does this mean for those  
> data? That they will be, sort of 'well-formed' to use an analogy  
> from the XML world, but not valid? Or they will be rejected? Or  
> they will be rejected by some tools, but not by others?

[snip]

Testing my understanding, because I was a bit confused on the call:

They will not be required to be supported in tools. That's the  
situation we have in OWL 1 for everything except xsd:string and  
xsd:integer.

The point of requiring more types is to try to raise the bar a bit.  
But if something is in wide spread use, there will be pressure to  
support it already (at least in some way). If we can find a clear way  
to support it without huge implementation burdens for corner cases,  
then we all agree we should require it.

The same with facets. We should only require those facets that are  
reasonable, i.e., likely to be used *and* proportionally reasonable  
to implement.

Cheers,
Bijan.
Received on Thursday, 19 June 2008 12:51:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 June 2008 12:51:09 GMT