Re: Controlling datatypes

On 21 Sep 2012, at 11:37, Christophe Guéret <c.d.m.gueret@vu.nl> wrote:

> 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?

because the group there are very slow and don't move fast. We would have liked for example a more flexible xsd:hexadecimal, that points to a number in hex for webid, and that can be written with spaces perhaps and new lines. That is because reading a long hexadecimal without spaces is very tedious, and because most software presents public keys like that - so it makes it easier for people to copy and paste. But the xsd crowd don't want to change that, even though frankly it would improve their spec. Sometimes simple things like that can make a difference.

I certainly think one should avoid making datatypes if possible, and indeed one should avoid inventing vocabulary if possible. But I am not sure why we need to specify something along those lines in this document... But let me get to reading it carefully.

> 
> 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)
> 
> 

Social Web Architect
http://bblfish.net/