- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Mon, 2 Mar 2015 15:41:50 +0000
- To: Dan Scott <dan@coffeecode.net>
- CC: Karen Coyle <kcoyle@kcoyle.net>, SchemaDot Org <public-vocabs@w3.org>
- Message-ID: <DM2PR0601MB1135B3E51DA1215CED823FDFAD100@DM2PR0601MB1135.namprd06.prod.outlook.>
Here's a revised suggestion for schema:circa that avoids the term "emerging": schema:circa a rdf:Property; rdfs:comment "Approximate date"; schema:domainIncludes schema:Thing; schema:rangeIncludes schema:Date, schema:Duration, schema:Event. Here are some specific examples of how schema:circa and schema:Role could be combined to indicate approximations of other date properties in schema: :A0 a schema:Painting; schema:name "Saint Praxedis"; schema:circa [ a schema:Role; schema:roleName schema:dateCreated; schema:circa "1655"; ]; schema:sameAs entity:Q94006; . :A1 a schema:Person; schema:name "Socrates"; schema:circa [ a schema:Role; schema:roleName schema:birthdate; schema:circa "-469/-468"; ]; schema:deathDate "-399"; schema:sameAs entity:Q913; . :A2 a schema:Organization; schema:name "Trade union"; schema:circa [ schema:Role; schema:roleName foundingDate; schema:circa :A3; ]. :A3 a schema:Event; schema:name "18th century in Great Britian"; schema:sameAs entity:Q6418949; . I'm thinking that schema:Event could be used to handle geological periods like "Jurassic". Those named events could then be assigned date properties so they could be collated. Like Richard, I'm less concerned about machine processing of approximate dates than I am in the ability to say something understandable. Jeff From: Young,Jeff (OR) Sent: Sunday, March 01, 2015 10:36 AM To: Dan Scott Cc: Karen Coyle; SchemaDot Org Subject: 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> >
Received on Monday, 2 March 2015 15:42:23 UTC