names and dates

[Bruce D'Arcus]

Issues of dates came up in another context, and I'd like to both present
the problem, and suggest a tentative solution.

As you all no doubt know, dates get typically encoded in RDF as some
variety of Dublin Core date literal, using XML Schema datatypes
(xsd:date, xsd:gYear, etc.).

This all works great, and allows RDF data to be reliably sorted,
displayed in different languages, etc.

The problem can be summarized by this list of dates:

i. 1334-1335
ii. 333 BC
iii. c1545
iv. May/June 2001
v. Winter 2002

So let's knock a few of these off as not so hard.

ii. "-0333"^^xsd:date

Hmm ... I guess that's the only one that's easy using standard datatypes ;-)

The DCMI Date Working Group* has been doing some work on some of the
other problems. I believe this work is likely to result in examples
something like:

i. "1334-1335"^^date:range
iii. "1545"^^date:approximate

I have no idea how it would handle the other two, but I don't think it a
good idea to be seeing data like:

dcterms:issued "Winter 2002"

For this reason, I'd suggest the simple solution is:

1. to use standard XSD date datatypes where possible
2. to follow the DCMI work to see if we can borrow from it for the use
cases they are committing to cover
3. to introduce a new literal property called something like
bibo:displayDate. It's sole purpose would be to store examples that
don't fit standard datatypes.

Also, see this from James Clark on Thai personal names:

<http://blog.jclark.com/2007/12/thai-personal-names.html>

We can treat foaf:name as a display date, though.

Bruce

* See <http://dublincore.org/groups/date/> and
<http://dublincore.org/datewiki/DateRequirements>

[John P. McCaskey]

>For this reason, I'd suggest the simple solution is:
>
>1. to use standard XSD date datatypes where possible
>2. to follow the DCMI work to see if we can borrow from it for the use
>cases they are committing to cover
>3. to introduce a new literal property called something like
>bibo:displayDate. It's sole purpose would be to store examples that
>don't fit standard datatypes.

Should it be required that if a displayDate is specified, a standard one be
specified also? A displayDate cannot really be used for sorting.

-- John

[Bruce D'Arcus]

John P. McCaskey wrote:
>> For this reason, I'd suggest the simple solution is:
>>
>> 1. to use standard XSD date datatypes where possible
>> 2. to follow the DCMI work to see if we can borrow from it for the use
>> cases they are committing to cover
>> 3. to introduce a new literal property called something like
>> bibo:displayDate. It's sole purpose would be to store examples that
>> don't fit standard datatypes.
>
> Should it be required that if a displayDate is specified, a standard one be
> specified also?

Yes, I think so.

Bruce

[Pipian]

On Dec 7, 2007, at 9:55 AM, Bruce D'Arcus wrote:

>
> Issues of dates came up in another context, and I'd like to both
> present
> the problem, and suggest a tentative solution.
>
> As you all no doubt know, dates get typically encoded in RDF as some
> variety of Dublin Core date literal, using XML Schema datatypes
> (xsd:date, xsd:gYear, etc.).
>
> This all works great, and allows RDF data to be reliably sorted,
> displayed in different languages, etc.

(snip)

It's a lot trickier than this, and this is one of the problems I'm
having to cope with in my other work relating to semantic web genealogy.

In particular, the first three examples throw real curveballs, and
that's because of the Julian calendar. While the concept of the
proleptic Gregorian calendar (the current calendar system as extended
back before its institution in 1582) is acceptable, and is what
xsd:date currently uses, the variations on dates (and relative
uncertainty of which system is being used, let alone bringing in other
systems like the Jewish calendar system) makes dates much more complex
than XML Schema made it out to be. Sure, we could convert every date
to Gregorian format, but specificity in this case is lost. This might
not be a problem for the Bibliontology, but it's something that not
many people have addressed.

Furthermore, for genealogical work, not only are specific dates,
ranges, and 'circa' dates necessary, but so are other qualifications,
like 'estimated' and 'calculated', and more importantly, these other
examples:

i. 1822-1824 (meaning FROM 1822 TO 1824, a duration)
ii. 1822-1824 (meaning BETWEEN 1822 AND 1824, a single time with
uncertainty given)
iii. before 1824
iv. after 1822

While specific, OWL-TIME[1] or the SOUPA time ontology[2] might cover
the semantics (ignoring the calendar system problem). On the other
hand, they may be too awkward to use.

Ian

[1] http://www.isi.edu/~pan/damltime/time-entry.owl
[2] http://pervasive.semanticweb.org/ont/dev/time

[Bruce D'Arcus]

Pipian wrote:

...

> It's a lot trickier than this ...

I know. As Dan Brickley once said to me when I made a similar point
about another issue: "it's always more complicated. That's the problem
with getting anything done." ;-)

So the question is: what's the most reasonable balance of simplicity an
generality? We need to make the 99% of dates out there that do
correspond to standard datatypes easy, after all.

Bruce

[Frederick Giasson]

I think we can think like SKOS here.

You do calculus wiith the standard specification (xsd:data datatype) and
display the bibo:displayDate if available (think about skos:prefLabel
and skos:altLabel).

Take care,

Fred

[Frederick Giasson]

Hi,

> I know. As Dan Brickley once said to me when I made a similar point
> about another issue: "it's always more complicated. That's the problem
> with getting anything done." ;-)
>
> So the question is: what's the most reasonable balance of simplicity an
> generality? We need to make the 99% of dates out there that do
> correspond to standard datatypes easy, after all.
>

Yes I agree. Anyway, there is my thinking:

Lets encourage the conversion to gregorian calandar for 99.9% of the
cases where it is possible. In fact, the semweb is all about converting
data from one thing to another thing :)

If one really can't express what he has to using bibo, why he couldn't
reuse the two ontologies you talked about to describe these dates? So it
becomes all about: reusing existing stuff to increase expression of an
ontology by using another ontology. There is nothing bad about that :)

Take care,

Fred

[Frederick Giasson]

Hi Ian,

> [1] http://www.isi.edu/~pan/damltime/time-entry.owl
>
Not available?

> [2] http://pervasive.semanticweb.org/ont/dev/time
>

Any documentation + examples for using this ontology?

Take care,

Fred

[Yves Raimond]

Hello!

> > [1] http://www.isi.edu/~pan/damltime/time-entry.owl
> >
> Not available?

The good URI is:
http://www.w3.org/TR/2006/WD-owl-time-20060927/
(W3C working draft)

Cheers!
y