Re: Is there an ISO 8601 based alternative to accrualPeriodicity in DCAT?

Thanks. That makes sense. For what it's worth, I can imagine using 8601
with only the repeating interval syntax (eg R/P1Y2M10DT2H30M) but not the
date (eg R/2008-03-01T13:00:00Z/P1Y2M10DT2H30M). Though as you said that's
not intuitive and would likely imply that full ISO syntax would be
acceptable.

The context for this is the Project Open Data (POD) schema which has tried
to align with DCAT. The current version of the POD schema was finalized
before the current version of DCAT stabilized, but there is work on an
updated version of the POD schema so there might be opportunities to better
align them. You can see a crosswalk at:

http://project-open-data.github.io/metadata-resources/

The question about accrualPeriodicity came up on this thread (
https://github.com/project-open-data/project-open-data.github.io/issues/292)
and it sounds like there's interest to using 8601 since it's already used
by other properties and provides this flexibility. Then the question is
whether to continue using that with the accrualPeriodicity term or use
another term. It sounds like your suggestion is to use a different term,
likely a new one.


On Tue, Jun 10, 2014 at 12:55 PM, Richard Cyganiak <richard@cyganiak.de>
wrote:

> Hi Philip,
>
> On 10 Jun 2014, at 17:18, Philip Ashlock - XI <philip.ashlock@gsa.gov>
> wrote:
> > So are you saying an 8601 formatted recurring date would fit within the
> range of dctype:Frequency but only if it didn't include a start or end date?
>
> I’m concluding this simply from the description of dctype:Frequency: “A
> rate at which something recurs.” Something like “Monthly” is a “rate”.
> Something like “On the 27th of July, August and September 2014” isn’t,
> strictly speaking.
>
> > The requirement is both to express other frequencies than cld:Frequency
> as well as more precise times.
>
> I see.
>
> Let me put it this way.
>
> Nobody can stop you from using any value you’d like with
> dcterms:accrualPeriodicity. The interesting question though is if you will
> see interoperability.
>
> There’s a good chance that another DCAT user who understands
> accrualPeriodicity would understand the cld:Frequency values, because they
> are sort of the obvious values to use with these properties.
>
> The chance that they would understand the ISO 8601 values would be lower.
> If those ISO 8601 values include not just a frequency but also a start
> and/or end date, then they might even be confused, because that’s not what
> you’d expect from reading the description of accrualPeriodicity and
> dcterms:Frequency.
>
> Therefore, in that case, it’s probably best to use a different property.
> You might have to define that property yourself if nothing suitable exists
> out there.
>
> Best,
> Richard
>
>
>
> >
> >
> > On Tue, Jun 10, 2014 at 7:29 AM, Richard Cyganiak <richard@cyganiak.de>
> wrote:
> > Hi Philip,
> >
> > On 9 Jun 2014, at 23:22, Philip Ashlock - XI <philip.ashlock@gsa.gov>
> wrote:
> >
> > > As far as I can tell accrualPeriodicity is limited to the predefined
> terms for frequency http://dublincore.org/groups/collections/frequency/
> >
> > I don’t think that’s the case. The range of dcterms:accrualPeriodicity
> is dctype:Frequency. It doesn’t follow that values are limited to
> cld:Frequency.
> >
> > (However, I do agree that a recurring interval with a start date is out
> of range for dctype:Frequency.)
> >
> > > Are there any existing terms that could be used in place of
> accrualPeriodicity using 8601 recurring interval syntax for more
> flexibility?
> >
> > I’m not aware of anything suitable.
> >
> > What is the requirement here? Express other frequencies besides those in
> cld:Frequency? Or express the precise time (e.g., not just monthly, but
> monthly on the 10th)?
> >
> > Best,
> > Richard
> >
> >
> >
> > --
> > Philip Ashlock
> > Chief Architect, Data.gov
> > U.S. General Services Administration
>
>


-- 
Philip Ashlock
Chief Architect, Data.gov
U.S. General Services Administration