[eml-dev] EML access and application behavior (metacat)
Margaret O'Brien
mob at icess.ucsb.edu
Fri Sep 19 09:48:03 PDT 2008
Inigo -
the changes to access were not in RC3, and are not quite all checked
into the head yet.
What is in head:
1. the cleaned-up type descriptions for res:DistributionType and
phys:PhysicalDistributionType: res:DistributionType is the base type
and a optional <access> is in in Physical. (here's the log:
http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/eml/eml-physical.xsd
This has no effect on instance documents
Not in head:
1. moving the access tree out of dataset (and analogous locations in the
other 4 modules as necessary)
2. retyping the 2nd <distribution> in software.xsd (see comment #2 in
bug 3480)
Big effect on instance docs
Actually, all these changes do is to make EML specs reflect a)
commonly-requested access restrictions, and b) what is feasible in
implementation. As Matt pointed out, the Metacat implementation already
honors only the access rules that refer to distribution ids and to the
entire document. It's just that in EML201, these rules were not placed
in the most logical locations. So the opportunities for authors to
complicate things are significantly reduced in EML210.
margaret
-------------
inigo san gil wrote:
>
> margaret, thanks for clarifying this! sorry didnt follow the thread
> more carefully.
>
> you say (see below) that it will appear in
> eml/dataset/dataTable/distribution/physical/access
>
> did the rel. candidate change the order of physical and distribution?
> wouldnt it be
> eml/dataset/dataTable/physical/distribution/access
> ..and if so, then the "distributionType" def (or/and the whole
> distribution module) would have to be changed for consistency, no?
>
> usually data access rules apply across the dataset, sometimes even
> across all organizational documents, which facilitates the
> access-rule-entry. i suppose you can give me plenty of examples of
> the contrary - no doubt. i understand the suggested changes gives the
> functionality desired, and makes both the access rule implementation
> feasible. i hope that most of the eml-users do not complicate their
> life trying to make degrees of accession to different parts of what
> they see as a dataset.
> one day we should discuss a real implementation that actually takes a
> serious attempt to implement restriction access - a whole entertaining
> matters that does not belong in this list
>
> cheers, inigo
>
> Margaret O'Brien wrote:
>> Hi Inigo -
>> Since we went to EML 2.1.0, that opened the door for other
>> backward-incompatible changes. One that was always targeted for 2.1
>> was to clean up the access rules. See bug 1132
>> (http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1132).
>>
>> In EML 2.0.1 datasets, access to the metadata was controlled at
>> eml/dataset/access, and for control of other nodes, authors were told
>> to add additonalMetadata sections with access trees and <describes>
>> elements pointing to the node they wanted the rules to apply to. But
>> in reality, node-level access control is too problematic to
>> implement. So the best solution is to identify the document parts
>> that people most want to control over, and put access trees where
>> their rules can be applied to those parts.
>>
>> The 2 places where authors most often want to control access are on
>> the entire metadata document, and the individual entities it
>> describes. This required 2 changes to EML 2.1:
>> 1. to make it clear that an access tree controlled the entire
>> package, <access> will be a sibling of dataset rather than a child.
>> 2. an access tree was added to the PhysicalDistributionType by
>> extension (see bug 3480 for that discussion, and my questions about
>> the use of the distribution tree)
>>
>> So, the upshot for EML-2.1.0
>> <access> will appear in these locations:
>> eml/access
>> eml/dataset/dataTable/distribution/physical/access
>>
>> See bugzilla for examples. And the documentation will state that
>> node-level access control is not reasonable. So while it is possible
>> to put an access tree into an additionalMetadata section, it's not
>> recommended, and authors shouldn't expect them to be recognized by
>> applications like metacat.
>> I havent thought much about the 201-to-210 xslt stylesheet yet, but I
>> think it should be able to handle moving the access trees around.
>>
>> Margaret
>> ===================
>>
>>
>>
>> inigo wrote:
>>>
>>> Dear Margaret,
>>>
>>> There is no <access> under <distribution>, isn't it? I think you
>>> meant under the main resource in (i.e;) <dataset>
>>> /eml/dataset/access
>>>
>>> cheers, inigo
>>> Margaret O'Brien wrote:
>>>> EML2.0.1: yes, what I was hoping.
>>>> EML2.1.0: I agree that recognizing access trees in
>>>> additionalMetadata is unnecessary. That's what I prefer - people
>>>> should use <access> under <distribution>, and discontinue putting
>>>> it in addionalMetadata altogether.
>>>>
>>>> life is simpler. thanks!
>>>> margaret
>>>>
>>>> Jing Tao wrote:
>>>>> Hi, Margaret:
>>>>>
>>>>> See my comments under the text.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jing
>>>>>
>>>>> Jing Tao
>>>>> National Center for Ecological
>>>>> Analysis and Synthesis (NCEAS)
>>>>> 735 State St. Suite 204
>>>>> Santa Barbara, CA 93101
>>>>>
>>>>> On Wed, 17 Sep 2008, Margaret O'Brien wrote:
>>>>>
>>>>>> Hi Jing -
>>>>>> I am updating the EML documentation for access. Per our
>>>>>> discussion last week, I just wanted to confirm the planned
>>>>>> behavior of metacat with regard to access trees in EML.
>>>>>>
>>>>>> 1. in EML 2.0.1, access is located at eml/dataset/access, and
>>>>>> authors may also have been putting in additionalMetadata/access
>>>>>> as well, accompanied by <describes>any_node_id</describes>
>>>>>> And you plan that metacat will
>>>>>> a. honor the eml/dataset/access tree (for all metadata and data) and
>>>>>> b. when it finds an access tree in an additionMetadata section,
>>>>>> it will recognize it only if it references an id on a
>>>>>> distribution element that is a descendant of dataTable -- or is
>>>>>> it honoring a reference to any distribution id (ie,
>>>>>> res:distribution).
>>>>>>
>>>>> Metacat currently is doing the way you described (maybe a little
>>>>> different).
>>>>> If no additionalMetadata/access in eml, the eml/dataset/access
>>>>> will be applied to EML document itself(metadata) and all data files.
>>>>>
>>>>> If there is additionalMetadata/access in eml and the id in element
>>>>> <describes> references a distribution element that is a descendant
>>>>> of dataTable (or other entities), the rules of
>>>>> additionalMetadata/access will be applied to the data table. The
>>>>> eml/dataset/access will be applied to EML document itself and
>>>>> other data files (if there is any) which are not in the
>>>>> <describes> in <additionalMetadata>.
>>>>>
>>>>>> 2. in EML 2.1.0, access will be found at eml/access and
>>>>>> /eml/dataset/dataTable/distribution/physical/access
>>>>>> And metacat will
>>>>>> a. continue to honor eml/access for all metadata and data, and
>>>>>> b. not recognize access trees found under additionalMetadata.
>>>>>> Does that mean it will ignore additionalMetadata/metadata/access
>>>>>> trees that were honored in 2.0.1, or can EML authors continue to
>>>>>> create these?
>>>>>>
>>>>> In the eml 2.1.0, my guess
>>>>> /eml/dataset/dataTable/distribution/physical/access is the
>>>>> replacement of additionalMetadata/access in eml 2.0.1. So there is
>>>>> no reason to continue to use additionalMetadata/access to controll
>>>>> the access of the data files in eml 2.1.0. So i think metacat can
>>>>> ingore additionalMetadata/metadata/access
>>>>> trees in eml 2.1.0 documents. What do you think?
>>>>>
>>>>>> thanks -
>>>>>> Margaret
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> ========================
>>>>>> Margaret O'Brien
>>>>>> Information Management
>>>>>> Santa Barbara Coastal LTER Marine Science Institute
>>>>>> University of California
>>>>>> Santa Barbara, CA 93106-6150
>>>>>>
>>>>>> 805-893-2071
>>>>>> mob at icess.ucsb.edu
>>>>>> http://sbc.lternet.edu
>>>>>> ========================
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
--
========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER
Marine Science Institute
University of California
Santa Barbara, CA 93106-6150
805-893-2071
mob at icess.ucsb.edu
http://sbc.lternet.edu
========================
More information about the Eml-dev
mailing list