Ticket #443 (new task)

Opened 13 years ago

Last modified 11 years ago

[M] (DI-3-3) Parse access constraints a bit more carefully

Reported by: selatham Owned by: sdonegan
Priority: desirable Milestone: NDG3
Component: discovery Version:
Keywords: WS-Discovery2 MDIP Cc:

Description

If possible make sense of when people say "Access constraints = none".

Change History

comment:1 Changed 13 years ago by selatham

  • Owner changed from selatham to lawrence

comment:2 Changed 13 years ago by selatham

  • Keywords WS-Discovery2 MDIP added
  • Milestone changed from SystemIntegrationOctober2006 to ReFactored_Discovery_WebServices

comment:3 Changed 12 years ago by lawrence

  • Owner changed from lawrence to ko23

Can't do much til in GUI til I see access constraints from Kev, so I'm passing the ticket to Kev until he hands it back :-)

comment:4 Changed 12 years ago by ko23

Errrrmmm "mini-MOLES" nis starting to look quite meaty.

For DIFs, try running xquery to see the entries.

declare default element namespace 'http://gcmd.gsfc.nasa.gov/Aboutus/xml/dif/';
for $DE in collection('/db/discovery')/DIF/Access_Constraints
return $DE

Anyone going for a role other than "secured" belonging to AA = the outputRepositoryID input to d2b* ?

comment:5 Changed 12 years ago by lawrence

this is a bit cryptic for me :-) what's your point ...

comment:6 Changed 12 years ago by ko23

Part A

  1. Mini-MOLES is growing beyond it's very basic beginnings: in no way a complaint, just an observation.
  1. There are 16 of the current DIFs that have Access_Constraint elements
    1. not that many at the moment, but is this representative of the future?
    2. there's no authorisation authority or role information in the Access_Constraint elements (no surprise), so one will have to be made up, hence the proposal for the AA and the associated role.

Part B (new bit)

  1. In MOLES, the access condition for the data set is an attribute of the data granule. It would be nice to point to a URL for the dataset, and, for DIF, these should be in either:
    • the Online_Resource element of Data_Set_Citation,
    • or a Related_URL with a qualifying URL_Content_Type element with a value of, or starting with, "GET DATA".

Unfortunately, there are content problems with both, but I'll just have to assume that the content problems will either go away or are as the data provider intended...

MDIP comments coming up IDC...

  1. Use constraints will be treated as access constraints until I've thought about it a bit more. Access constraints are easy, either they can go with the data granule, or there isn't a way to get at the dg (anyone got comments about this? I think we covered combining granule access rights in the past). Could the same approach work with use constraints? or should there be a separate access/use section for the DE, and what would its relation to the dg's equivalents be?

Anyway see first 2 sentances of the above for my intended stop-gap.

  1. New and improved XQuery corner to spot the offenders in the DIF and MDIP imports
    declare namespace dif='http://gcmd.gsfc.nasa.gov/Aboutus/xml/dif/';
    declare namespace mdip ='http://www.oceannet.org/mdip/xml';
    for $DE in collection('/db/discovery')/(dif:DIF[exists(dif:Access_Constraints) or exists(dif:Use_Constraints)] | mdip:Metadata[exists(mdip:AccessConstraint) or exists(mdip:Use_Constraints)])
    return $DE
    

and now we have 18...

  1. Consistency corner: the MDIP schema 1.2 has "AccessConstraint" and "UseConstraints" elements or have I missed an update?

I think I'll take a breath now...

comment:7 Changed 12 years ago by selatham

  • Owner changed from ko23 to selatham

Access constraints originating from NDG style look like below. Otherwise they tend not to exist so the problem of AccessConstraints? = None is probably low priority now.

<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_decadal_ocean: Effect: allowneeds from</Access_Constraints>
<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_seasonal_ocean: Effect: allowneeds from</Access_Constraints>
<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_seasonal_atmos: Effect: allowneeds from</Access_Constraints>
<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_monthly_atmos: Effect: allowneeds from</Access_Constraints>
<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_annual_atmos: Effect: allowneeds from</Access_Constraints>
<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_annual_ocean: Effect: allowneeds from</Access_Constraints>
<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_monthly_ocean: Effect: allowneeds from</Access_Constraints>
<Access_Constraints>For data granule COAPEC_500YrRun_wholerun_decadal_atmos: Effect: allowneeds from</Access_Constraints>

comment:8 Changed 11 years ago by lawrence

  • Owner changed from selatham to sdonegan
  • Milestone changed from Reporting to NDG3

I think the issue now reduces to making sure that access constraints pass through the discovery service unchanged, and in a way that puts up a key icon. It's also about documentation. Feel free to close this ticket in favour of some more specific actions.

comment:9 Changed 11 years ago by sdonegan

  • Summary changed from [M] Parse access constraints a bit more carefully to [M] (DI-3-3) Parse access constraints a bit more carefully
Note: See TracTickets for help on using tickets.