Re: Encoding an incomplete date as xsd:dateTime

It may be worth reminding ourselves (?) that in RDF you can use “all of the above”.
That is, if you want to make your RDF as consumable as possible, you may well represent the same stuff using more than one ontology.
This is true of lots of things, such as peoples’ names or different bibliographic ontologies (although sometimes subproperty will do), but is particularly true for date and time.

http://www.w3.org/TR/owl-time/
has an example at the end:

:meetingStart
      a       :Instant ;
      :inDateTime
              :meetingStartDescription ;
      :inXSDDateTime
              2006-01-01T10:30:00-5:00 .

:meetingStartDescription
      a       :DateTimeDescription ;
      :unitType :unitMinute ;
      :minute 30 ;
      :hour 10 ;
      :day 1 ;
      :dayOfWeek :Sunday ;
      :dayOfYear 1 ;
      :week 1 ;
      :month 1 ;
      :timeZone tz-us:EST ;
      :year 2006 .
and it might well be the case that you would have both (and other representations) in your dataset, and of course you would only assert the bits of the second representation that were appropriate.

Of course, that doesn’t answer your original question, Heiko (sorry!), about what the xsd version should look like.

Hugh

On 10 Feb 2014, at 15:53, Niklas Lindström <lindstream@gmail.com> wrote:

> Hi Heiko,
> 
> Unless you want to use another ontology (e.g. BIO [1][2] or schema.org [3]), I'd probably go ahead and break that contract, although it is not technically safe (AFAIK, it's a violation of OWL semantics). It depends on the expected consumption of your data.
> 
> I would say that the vcard ontology formally needs to be fixed to allow for more variation. It actually seems to have been amended somewhat in 2010 [4], to at least not require the exact second (or fraction thereof) of the birth. But that's hardly enough. A lot of the point of datatyped literals in RDF is lost when datatype properties are locked down like this.
> 
> Cheers,
> Niklas
> 
> [1]: http://vocab.org/bio/0.1/.html
> [2]: http://wiki.foaf-project.org/w/BirthdayIssue
> [3]: http://schema.org/birthDate
> [4]: http://www.w3.org/Submission/2010/SUBM-vcard-rdf-20100120/
> 
> 
> 
> 
> On Mon, Feb 10, 2014 at 3:55 PM, Heiko Paulheim <heiko@informatik.uni-mannheim.de> wrote:
> Hi Jerven,
> 
> this looks like a pragmatic solution. But I wonder if it may lead to any conflicts, e.g., the vcard ontology defines the bday property with xsd:dateTime as its range explicitly. Is it "safe" to simply use an xsd:gYear value as its object?
> 
> Best,
> Heiko
> 
> 
> 
> Am 10.02.2014 15:43, schrieb Jerven Bolleman:
> 
> Hi Heiko,
> 
> http://www.w3.org/TR/xmlschema-2/#gYear and http://www.w3.org/TR/xmlschema-2/#gYeargYearMonth
> are the datatypes that you should use.
> 
> Regards,
> Jerven
> 
> On 10 Feb 2014, at 15:37, Heiko Paulheim <heiko@informatik.uni-mannheim.de> wrote:
> 
> Hi all,
> 
> xsd:dateTime and xsd:date are used frequently for encoding dates in RDF, e.g., for birthdays in the vcard ontology [1]. Is there any best practice to encode incomplete date information, e.g., if only the birth *year* of a person is known?
> 
> As far as I can see, the XSD spec enforces the provision of all date components [2], but "1997-01-01" seems like a semantically wrong way of expressing that someone is born in 1997, but the author does not know exactly when.
> 
> Thanks,
> Heiko
> 
> [1] http://www.w3.org/2006/vcard/ns
> [2] http://www.w3.org/TR/xmlschema-2/#dateTime
> [3] http://www.w3.org/TR/xmlschema-2/#date
> 
> -- 
> Dr. Heiko Paulheim
> Research Group Data and Web Science
> University of Mannheim
> Phone: +49 621 181 2646
> B6, 26, Room C1.08
> D-68159 Mannheim
> 
> Mail: heiko@informatik.uni-mannheim.de
> Web: www.heikopaulheim.com
> 
> 
> 
> 
> 
> -- 
> Dr. Heiko Paulheim
> Research Group Data and Web Science
> University of Mannheim
> Phone: +49 621 181 2646
> B6, 26, Room C1.08
> D-68159 Mannheim
> 
> Mail: heiko@informatik.uni-mannheim.de
> Web: www.heikopaulheim.com
> 
> 
> 

-- 
Hugh Glaser
   20 Portchester Rise
   Eastleigh
   SO50 4QS
Mobile: +44 75 9533 4155, Home: +44 23 8061 5652

Received on Monday, 10 February 2014 18:24:43 UTC