Re: Circa. dates

Jeff, the problem is that adding a new property only handles one part of a
range of necessary date. That is, it is primarily CreativeWork
publication/release oriented, and even then handles only one of dateCreated
/ dateModified / datePublished. You could use schema:circa in place of
schema:birthDate, maybe, but it would be hard to reuse it for
schema:deathDate if defined as "emerging". Maybe you could apply
schema:circa in combination with a second date-oriented property to suggest
that the date is "-ish" but that would require a schema.org-specific
interpretation.

I think the original 2012 discussion had the right suggested approach in
terms of LoC's draft level 1 extension to ISO8601. Rather than doing
anything schema.org-specific I would be much more comfortable adopting &
encouraging an extension that has practical applications in a much broader
domain.
On 28 Feb 2015 21:07, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:

> I would be happy with something like this:
>
> schema:circa
>     a rdf:Property;
>     rdfs:comment "A rough approximation of the temporal period when the
> thing emerged";
>     rdfs:domainIncludes schema:Thing;
>     rdfs:rangeIncludes schema:Date, schema:Duration, schema:Event.
>
> Jeff
>
>
>
> > On Feb 28, 2015, at 5:27 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> >
> > Also note that some of the "circa dates" attempt to narrow down the date
> to a century or a decade. In library data this is done with "19uu" or
> "196u" with "u" standing for unknown, of course. In one system we indexed
> these as ranges, e.g. 1900-1999, 1960-1969, which worked for our date
> search algorithm but is of course is ambiguous (is it really a range? or is
> it an approximation?). Another interesting date that appears in archives is
> the "flourished" date -- this gets used for writers and artists for whom
> the time period of their work is known but their bio information has not be
> recorded for the ages.
> >
> > That said, I'm wondering what the use case is for defining these dates
> as "circa" or "flourished" in schema.org. One of the really useful things
> about schema.org is that you keep the display form, in this case "c.
> 1765", for human consumption, but can also include a coded form that is
> actionable. Question is, what is that action, and is "circa" something that
> the action with act on?
> >
> > kc
> >
> >> On 2/28/15 9:51 AM, Wallis,Richard wrote:
> >> Hi all,
> >>
> >> With colleagues I have been looking at how we might handle historical
> >> approximate dates in Schema.org <http://Schema.org>.  The initial
> >> requirement being to be able to describe an old book or manuscript
> >> published say in approximately 1765.  A common need in the bibliographic
> >> world, with the normal string based solution being “circa. 1765”, or “c.
> >> 1765” - Wikipedia providing some examples
> >> <http://en.wikipedia.org/wiki/Circa>.
> >>
> >> The knee-jerk reaction was to suggest some sort of
> >> approximateDateCreated property for CreativeWork which would not only
> >> help us bibliographic folks but also those in museums and galleries with
> >> similar date approximation needs.
> >>
> >> Broadening the analysis it became clear that this need could be
> >> applicable in most any case where you would expect a Date
> >> <http://schema.org/Date> in the range of a property.  birthDate,
> >> deathDate, dateCreated, datePublished, foundingDate, all being all
> >> potential candidates for Circa style dates.  Rolling things into the
> >> future you could imagine other examples such as wanting to describe the
> >> last serviced date of a vehicle being circa 2013.
> >>
> >> So how to solve this in a simple, yet generic, way?
> >>
> >> We could take advantage of the default "if you haven’t got a specified
> >> type for a property, a Text is acceptable” pattern in Schema, and just
> >> put in a text string with a defined format: “c.1765”.
> >>
> >> Perhaps a more appropriate solution would be to define a new data type,
> >> to be added to the range of suitable properties.
> >>
> >> My pragmatic (KISS and don’t break stuff) view of this leads me to
> >> suggest a new data type named ‘circaData’, or maybe 'approximateDate' as
> >> a subType of Date.  With descriptive information in the Type definition
> >> explaining why/how you would use it in the use cases I describe above.
> >>
> >> This approach would add this important functionality, for those
> >> describing old stuff, without the need for major upheaval across the
> >> vocabulary, and would at least default to a date for those that do not
> >> care or look for such approximation aspect of dates.
> >>
> >> ~Richard
> >>
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > m: 1-510-435-8234
> > skype: kcoylenet/+1-510-984-3600
> >
>
>
>