Issue 111 in void-impl: Change frequency estimate

[void...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Product-vocab

New issue 111 by kjet...@gmail.com: Change frequency estimate
https://code.google.com/p/void-impl/issues/detail?id=111

I'm working on caching semweb resources now, and since HTTP allows
calculation of heuristic freshness, see
http://tools.ietf.org/html/rfc7234#section-4.2.2 it would be interesting to
have properties that could be used for this. We have dct:issued and
dct:modified of course, and the combination of those and a
void:changeFrequency could be used for calculating heuristic freshness.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[void...@googlecode.com]

Comment #1 on issue 111 by kjet...@gmail.com: Change frequency estimate
https://code.google.com/p/void-impl/issues/detail?id=111

Now, my paper on this topic has been accepted to ESWC 2015 Research Track:
http://folk.uio.no/kjekje/#cache-survey

That there should be a change frequency predicate are amongst the
recommendations I make in there. :-)

Looking into the datatypes, I think that it might be most appropriate to
use a duration datatype, e.g. the XPath 2.0 datatypes xs:yearMonthDuration
and xs:dayTimeDuration.

[void...@googlecode.com]

Comment #2 on issue 111 by kjet...@gmail.com: Change frequency estimate
https://code.google.com/p/void-impl/issues/detail?id=111

Uh, forgot the link: http://www.w3.org/TR/xpath-functions/#duration-subtypes

[Kjetil Kjernsmo]

Dear all,

I see that my updates to the issue tracker came out as rather opaque in
this mailing list, and I should clarify what I'm up to.

I'm working on caching of Linked Data, and also of SPARQL queries. I did a
survey about the prevalence of that on the Semantic Web just now, which
has been accepted to ESWC Research Track. Do not fear, it is pretty
practical: http://folk.uio.no/kjekje/#cache-survey

If you have the Cache-Control or Expires headers, you're fine, but often
you don't have that, and then, it would be useful if you could estimate
the freshness lifetime from heuristics. You might now when a certain
dataset was last updated, and if you know how often it is supposed to
change, you can use that.

There's a dct:accrualPeriodicity predicate in Dublin Core Terms, but it is
not widely used, and the lexical space isn't properly constrained, so it
isn't terribly useful.

Therefore, I think something like that should be in VoID. I mentioned in
the paper, but it was beyond its scope to design something like that
properly.

I had a look at various data types to constrain the lexical space and I
found that XPath 2.0 has attempted to rectify some problems with
xsd:duration: http://www.w3.org/TR/xpath-functions/#duration-subtypes
There's xs:yearMonthDuration and xs:dayTimeDuration, which seems
appropriate for this use.

So, a little brainstorm here:
void:expectedUnchangedFor
void:validFor
void:changePeriodicity
void:changeFrequency
void:unchangeDuration

Well, each has its pros and cons. Anyway, I really think this should go
in, so please help me out here! :-)

Best,

Kjetil