Hello Peter, gYear and similar types are poorly supported, because Virtuoso is an SQL RDBMS with SQL datatypes inside. So they're casted to SQL dates and times. I'm trying to improve the support to mimic XML Schema types better but I had to change things accurately and gradually because customers have 15 years long history of applications that depend on current semantics. I can not promise fast progress, sorry.
For B.C. dates, the situation is even worse, because recently the XML Schema spec has changed the meaning of B.C. string representation. In 2004 and earlier versions, "D.3.2 No Year Zero" paragraph states exactly what's in its header: there is no year "0000", the year before "0001" is "-0001". However 2004 version warns that "It is the intention of the XML Schema Working Group to allow '0000' as a lexical representation in the dateTime, date, gYear, and gYearMonth datatypes in a subsequent version of this Recommendation. '0000' will be the lexical representation of 1 BCE (which is a leap year), '-0001' will become the lexical representation of 2 BCE (not 1 BCE as in this (1.0) version), '-0002' of 3 BCE, etc." I.e. they intend to change the representation and there will be no clue in a string whether it contains "old" or "new" notation of a B.C. year. For millions of years I'd just keep number of years, because most of processors treat more than 4 digits of the year as a syntax error. The reason is that some old systems recorded dates as 8 digits without any delimiters, like "20120126" and a long year may trigger the parsing according to that format. Best Regards, Ivan Mikhailov OpenLink Software http://virtuoso.openlinksw.com On Wed, 2012-01-25 at 15:26 -0500, Peter DeVries wrote: > Hi, > > > I have an issue in how to represent years. > > > I have been using the following in my RDF > > > <txn:yearDescribed > rdf:datatype="http://www.w3.org/2001/XMLSchema#gYear";>1771</txn:yearDescribed> > > > However I noticed two problems: > > > 1) When viewed from within Virtuoso as seen in this screenshot. > > > The year is changed to the January 1st of the year. I think that date > would do the same thing. > > > http://assets.taxonconcept.org/ss/YearIssue.png > > > 2) This OWL 2 validator seems to have problems with > <http://www.w3.org/2001/XMLSchema#gYear> it does not see it as valid > > > Any ideas on how to handle years so that one could infer that 1824 is > later than 1758. > > > Also what should be done regarding things like > > > 20 - 30 million years ago? > > > Thanks, > > > - Pete > > > ------------------------------------------------------------------------------------ > Pete DeVries > Department of Entomology > University of Wisconsin - Madison > 445 Russell Laboratories > 1630 Linden Drive > Madison, WI 53706 > Email: pdevr...@wisc.edu > TaxonConcept & GeoSpecies Knowledge Bases > A Semantic Web, Linked Open Data Project > -------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ Virtuoso-users mailing list > Virtuoso-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtuoso-users
