It's easy to markup a recipe's cooking or preparation time if it's for a specific time range:
Prep time: <time datetime="PT30M" itemprop="prepTime">30 min</time>
Cook time: <time datetime="PT1H" itemprop="cookTime">1 hour</time>
However, many recipes use estimated durations instead:
Prep time: 10-30 minutes
Cook time: 1 - 1½ hours
What's the best way of marking this information up in a way that'll be picked up by Google? From what I can tell, the ISO 8601 duration format doesn't seem to support "fuzzy" durations/duration ranges.
It's tempting to interpolate the time range so the machine-readable value sits halfway between the human-readable min/max values:
Prep time: <time datetime="PT20M" itemprop="prepTime">10-30 minutes</time>
Humans see: 10-30 minutes
Google/machines see: 20 minutes
That feels hacky and forced, though, and also feels like I'm feeding search engines incorrect data with specifics for the sake of SEO.
Short answer: I don’t think the time element as currently specified provides any good way to specify “fuzzy” durations.
Longer answer
This is by design a known issue/limitation in the current definition of the time element in the HTML spec. There’s been discussion about it, and some proposals for extending the scope of time to address that use case; see https://wiki.whatwg.org/wiki/Time_element#Fuzzy_dates
The proposal that’s had the most traction is to add a certainty attribute to time that would allow you to do something like this:
Prep time: <time datetime="PT20M" certainty="10M">10-30 minutes</time>
Along with that certainty-attribute idea, there’s also been discussion of updating the specs for actual time formats to include a way to use ? or ~ characters to specify approximations; see http://www.loc.gov/standards/datetime/pre-submission.html#uncertain
Anyway, there’s not yet been agreement about any of the proposed solutions, so gist of it remains that there’s unfortunately not yet any standard way to express a fuzzy duration—and I think also not really even any very good workarounds other than the one mentioned in the question.
Related
In official documentation I can't find any information how to write conditional statements for java.util.Date type fact fields in guided rules. For example how to compare such field to current date, check if it is equal omitting time, or check if it is date before some time from now?
Drools isn't a real-time program and it doesn't have an innate idea of Time or Now. If you need to investigate relations of some fact property w.r.t. some point of time X, you'll have to establish a fact carrying X as its data, and write your rules based on that.
A more or less coarse approximation of a fact representing Now can be made using timers. You can implement a rule that modifies a fact containing a value representing Time (e.g. java.util.Date) every second, or less frequently.
Blending out the time of the day is something you'll have to do using Java or DRL functions. Alternatively, if it is days you are interested in, use some custom class representing days, with some suitable day 1 defined by you.
you can give like
inputDate>=11-Nov-2014
provide your current date to inputDate rule input Fact variable.
An API defines that a date should be sent as iso8601, but we have a requirement to send "forever" as a date, and the standard does not seem to cover this. Can anyone suggest a better solution than Dec 31 9999? Is there a different standard that would be more appropriate?
Quoting ISO 8601:2004(E):
3.5 Expansion
By mutual agreement of the partners in information interchange, it is permitted to expand the component
identifying the calendar year, which is otherwise limited to four digits. This enables reference to dates and
times in calendar years outside the range supported by complete representations, i.e. before the start of the
year [0000] or after the end of the year [9999].
And also relevant may be section 3.7 Mutual agreement which basically says you're free to define your own representations as long as you don't interfere with the representations defined in ISO 8601. So 9999-12-32 or 9999-13-00 could be mutually agreed upon for your proposed forever value.
As to what's common practice, I'd say it depends.
I'd go for 3.7 whenever possible. But it's important to assess your role within the whole set-up. E.g. if you're using a 3rd party API within your own set of components for the sake of convenience or future compatibility, there should be no problem at all. If you're part of a bigger system and you'd have to convince tens of other system parties/components/modules/etc. I'd say it's not worth the trouble.
Also very important to check legacy code. And at least sketch out a plan on how to do the migration in case it breaks set-ups beyond belief. That could be anything from documenting your API "extension" to actually sending patches to the legacy code maintainers.
When defining a model in ACT-R, I would like to set for each of my productions, a different firing time.
How could I do that?
Thanks!
Not too many ACT-R modelers here, huh?
First off, keep a copy of the ACT-R reference manual handy. This a great resource that answers 90% of the questions you will have.
You can set a production's action time using (spp <production-name> :at <time>) or you can set the default action time using (sgp :dat <time>). Times are in seconds, so the default is .05.
That being said, you should modify these parameters very rarely, if at all. The whole point of production firing time is that it's supposed to represent a psychological constant. If you're tinkering with this, your model may fit the data but is less likely to be psychologically plausible. And if you don't care about psychological plausibility, then you shouldn't be using ACT-R! But there's an exception to every rule, so proceed with caution.
While this is a bit old, this question still comes up fairly high on Google when searching for ACT-R production firing times, so I feel it is acceptable to post a response.
As a published ACT-R modeler with 4 years under my belt, I would like to echo Jeff's statements. You very, very rarely modify most ACT-R parameters for the exact reason Jeff stated. All aspects of ACT-R and the amount of time certain modules take to fire are empirically backed by many studies. If you start changing these, then your model, like Jeff said, is completely implausible. While some modelers do change these values, they have empirical data to back up their reasons for changing any parameters.
I've been searching for a definitive answer to this, and the XML schema data types document seems to suggest that timezones are accepted, yet I found at least one implementation which does not properly convert time zones ( NUSOAP ).
To make sure that the problem is not at my end, I'd like to know if a format such as 2009-11-05T11:53:22+02:00 is indeed valid and should be parsed with timezone information, i.e. as 2009-11-05T13:53:22.
Given the following sentences from the w3c schema documentation:
"Local" or untimezoned times are
presumed to be the time in the
timezone of some unspecified locality
as prescribed by the appropriate legal
authority;
and
When a timezone is added to a UTC
dateTime, the result is the date and
time "in that timezone".
it does not sound like there is a definitive answer to this. I would assume that it is the usual ambiguity: Both versions are principally valid, and the question of what version to use depends on the configuration/behavior/expectations of the system one is interfacing with.
And even if there where a definitive answer, I would definitely not rely on it, but rather expect that every other web service and library had its own way of dealing with this :/
You converted the timezone incorrectly.
2009-11-05T11:53:22+02:00
is equivalent to
2009-11-05T09:53:22Z
Is that what NUSOAP did?
Has anyone found a simple, but effective way to extract date references from text? I've done a fair amount of searching for temporal extraction tools, but there isn't a lot out there. There are a few white papers, but it seems to fall into a subset of the whole semantic web thingy but not given much attention.
I'm just looking for something that is 80% effective. There is no need to capture things like "the month after Jan 2009", but basic common dates entities would be nice.
I'm open to all suggestions, even fancy regex expressions.
Fire away!
(and thanks - Henry)
If the target temporal expressions in your data are only in limited format, use regular expression and iterative approach to refine your system
Otherwise, use Stanford NLP toolkit, SUTime, which might be an over-kill but definitely meet your demands
One way I have done this is to just look for anything that is 4 numbers and convert it to a number. If the number falls within the range of years you are interested in, you probably have a year you can use. If you are interested in any matching months and days you could check adjacent words to see if they are a month name or a number between 1 and 31. I am confident this would satisfy your 80% requirement.
Regex for years: [0-9]{4} - you will need to convert to a number and see if it's within the range of years you consider valid.
Regex for months: jan|january|feb|february ... etc for each month
Regex for days of the month: [0-9]{1,2} - you would need to convert to a number and see if it is 1-31
I'm drawing a blank on how to find what to feed it, but this library will parse a wide range of dates and could be used as the "is this a real date" function. (Full disclosure, I'm the author of that lib)