[eml-dev] EML access and application behavior (metacat)

Wed Sep 17 17:04:16 PDT 2008

Nice explanation, Margaret.  I'd like to add that EML 2.0.1 also did not
support access control rules on arbitrary subtrees.  Rather, it only
supported 'resource-level' access rules for the whole document and access
rules that applied to the data entities themselves.  These latter rules were
assigned in additionalMetadata, but the rules could only be pointed at
specific parts of the EML document -- namely at the id of the distribution
element.  EML 2.0.1 explicitly states that all other access control
directives should be ignored.  Thus, for 2.1, all we are doing is changing
the locations of these two types of access directives to make it clearer how
they apply to the document.  The current EML spec describes the situation
fully for EML 2.0.1:

http://knb.ecoinformatics.org/software/eml/eml-2.0.1/eml-access.html

Matt

PS EML 2.0.0 allowed acls that pointed at arbitrary subtrees and therefore
allowed non-deterministic scenarios to arise, but these problems were
remedied in EML 2.0.1.

On Wed, Sep 17, 2008 at 3:24 PM, Margaret O'Brien <mob at icess.ucsb.edu>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
> ========================
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20080917/d0435525/attachment-0001.html>