Re: Controlling datatypes

Hi,

Two questions for you:
>
> 1/ What about the geospatial geometry example?
>
I would argue that this is a Literal. From a programming point of view, it
is up to the software to decode the value anyway. Whatever a custom data
type is used or not, the software will have to decode it. And the
information on how to decode it won't be given by de-referencing the data
type so that's something the developer will implement. I don't see how
allowing for custom data types would make this any easier considering that
there will be many custom data type created to represent a Point in space.

2/ Such data exists and will exist.  Just because you/we don't think it
> is modeled right, do we prohibit from LDP?
>
We can write has many recommendations and best practices as we want, users
will always do whatever they want with them - and this is right. The
question here is not whether such data exist and if it is "rightly" modeled
(that's quite subjective anyway), I think the goal of LDP should be to
establish the default, expected, behavior. If some data producers have data
that require a custom data type they will create it anyway, even if there
is a "must" in the recommendation.

Yet, the default behavior should cover most use-cases. I think xsd:gYear
mixes a bit the measure and its value, but it is so convenient and so
widely used that it should be a basic type. Maybe the same could be said
about geographical points. If there is a need for an xsd for it, what not
create it?

Christophe

-- 
Dr. Christophe Guéret (christophe.gueret@dans.knaw.nl)
http://www.few.vu.nl/~cgueret/
http://semweb4u.wordpress.com/
Postdoctoral researcher working on CEDAR (http://cedar-project.nl/)
Royal Netherlands Academy of Arts and Sciences
Data Archiving and Networked Services (DANS)