[Seavox] Restrictions - final?

[Birkel, Paul A.]

Roy;

According to 19115 Table 3 "Core metadata for geographic datasets" the
use of MD_Constraints (and subclasses) is not considered part of "core
metadata for geographic datasets' (section 6.5).  My estimation is that
constraints are considered to be part of "use-type" metadata rather
than what would be considered the "core function" of discovery.  So
regarding what I understand to be the intent of your question, I think
that you're "in the clear" :-).

paul

>-----Original Message-----
>From: seavox-bounces at biwebs1.nerc-liv.ac.uk
[mailto:seavox-bounces at biwebs1.nerc-
>liv.ac.uk] On Behalf Of Roy Lowry
>Sent: Thursday, November 30, 2006 4:39 AM
>To: seavox at biwebs1-2.nerc-liv.ac.uk
>Subject: [Seavox] Restrictions - final?
>
>Dear All,
>
>Attached is a modified version of the restrictions vocabulary, which
has changed as
>follows:
>
>(1) Definitions have been tweaked to (hopefully) address your comments
>(2) Julie's extra cost category has been added
>(3) An extra entry has been added to cover cases raised by BODC
colleagues where
>data are freely available to some but not to all
>
>Two issues with this vocabulary have occupied my thoughts over the
past week
>
>(1) Should I add something for the case of restricted unless
synthesised?  The
>conclusion was no on the basis that this is one of many potential
specific usage
>conditions. The intention with this vocabulary is to give data set
discoverers an idea of
>what they are in for should they decide to access a discoverd data set
rather than
>labelling data sets with their access conditions.  I would label
datasets of this type as
>'licence' not 'restricted' to indicate that some type of accessibility
was possible within a
>standard framework without the need for negotiation.
>
>(2) Should I be doing more to rationalise with the related lists in
ISO19115, particularly
>MD_ClassificationCode and MD_RestrictionCode?  Again I concluded no.
These lists
>are obviously targeted at the military and commercial sectors
respectively.  We are in a
>different sector and therefore what we should be doing is 'profiling'
- taking terms that are
>relevant then extending.  My only concern with this is that I am
unclear what constitutes
>the 'ISO19115 core' in this case.  Can anybody enlighten me?
>
>I'll load up this vocabulary into the server on Monday after which
time the rules of change
>are 'terms may be added and definitions broadened' unless anyone
argues that I should
>do otherwise.
>
>Cheers, Roy.