Re: Circa. dates

One option would be to use schema:Role to split schema:circa in two halves and then use schema:roleName to assign the specific property that is being fudged. It's just another example of what Role is for.

Jeff


On Mar 1, 2015, at 8:00 AM, Dan Scott <dan@coffeecode.net<mailto:dan@coffeecode.net>> wrote:


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 handlesonly 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<http://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<http://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<mailto: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<mailto: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<http://schema.org>. One of the really useful things about schema.org<http://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> <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<mailto:kcoyle@kcoyle.net> http://kcoyle.net
> m: 1-510-435-8234<tel:1-510-435-8234>
> skype: kcoylenet/+1-510-984-3600<tel:%2B1-510-984-3600>
>