- From: Gannon Dick <gannon_dick@yahoo.com>
- Date: Wed, 23 Jun 2010 10:28:14 -0700 (PDT)
- To: eGov IG <public-egov-ig@w3.org>
> --- On Wed, 6/23/10, Martin Alvarez-Espinar <martin.alvarez@fundacionctic.org>
> wrote:
>
>
> > * Property 'Frequency' [1] needs to have a
> 'dct:Collection'
> > as Domain. So, a Catalog must be a 'dct:Collection' as
> well.
> > (I've modified this on the wiki).
>
> This has bothered me for a while. I think yours is
> the right solution for Frequency, but the DCMI might help
> things a bit if they defined a 'Channel' Element (one
> frequency) in DCAM as they do dct:Agent and dct:AgentClass.
>
> > * Property 'Temporal Coverage' [2] could have literal
> > values, typed as xsd:duration (based on the ISO 8601
> > standard)? Defined as 'PnYn MnDTnH nMnS'.
>
> This is philosophically related to the above. A Frequency
> Spectrum [or Duration] and a Collection of Properties is
> distinction which means more to an Engineer than a Wordsmith
> :) There are some very nicely done (free) applets to
> explore the workings of the Fourier Transform available.
>
> > * Property 'keyword/tag' [3] should not restrict its
> range
> > to 'Literal'. Some tags might be added as a Resource.
> For
> > instance, Faviki [4] uses semantic tags. Other example
> might
> > use tags from a controlled vocabulary in SKOS.
>
> The DCMI famously does not have a 'keyword' element because
> the dct:subject Element should have a 'type' context
> associated, at least implicitly. I agree that the
> range on dct:subject should not be restricted.
> However, one needs to realize that the actual synonyms at
> play are: subject/text, keyword/text and tag/text,
> otherwise, meta data and semantics can be very
> uncooperative.
>
> --Gannon
Received on Wednesday, 23 June 2010 17:28:47 UTC