Re: Revision of FilterQuery proposal

[Len Gallagher <LGallagher@nist.gov>]

Team,

Some in-line comments below.

-- Len



At 08:22 PM 10/5/01, Farrukh Najmi wrote:
>Len,
>
>I need a clarification.
>
>It appears that given the latest filter query proposal may not allow 
>retrieval of
>things like Classification, Association, ExtrenalLink, ExternalIdentifier 
>based
>upon any of the following branches:
>
>SourceAssociationBranch
>TargetAssociationBranch
>HasClassificationBranch
>SubmittingOrganizationBranch
>ResponsibleOrganizationBranch
>ExternalIdentifierBranch
>ExternalLinkBranch
>HasSlotBranch
>HasAuditableEventBranch
>
>Please let me know if I am mistaken about the above perception.


That's correct. FilterQuery does not support direct retrieval of things 
like Association instances and Classification instances. Instead, 
Associations are treated as queryable links between RegistryEntry instances 
and Classifcation instances are queryable links between RegistryEntry 
instances and a specific node of some classification scheme.

Also, ExternalLink and ExternalIdentifier are treated as queryable 
properties of RegistryEntry instances rather than as stand-alone 
retrievable objects.



>Recall that the ability to find Classification, Association, ExtrenalLink,
>ExternalIdentifier etc. by their classification was supported by existing 
>browse
>and drill down queries.


That's true. The GetClassifiedObjectsRequest discussed in section 8.1.3 
would take a list of ClassificationNode UUID's as input and return all 
RegistryObject instances classified by each of those nodes. Thus, 
GetClassifiedObjectsRequest, is sort of a polymorphic query that returns 
objects of different subtypes. Instead, FilterQuery retrieves only one kind 
of subtype at a time, i.e. RegistryEntry, Organization, AuditableEvent, 
etc. The important classification of things like ExternalIdentifier 
instances would be carried as an attribute. Recall our discussions on 
whether the name attribute of ExternalIdentifier should carry the "type" of 
ExternalIdentifier (e.g. GUID, SSN, EID, URN, UUID, etc) or if we should 
rename that attribute to "extIdType", or define a new attribute 
"extIdType". FilterQuery assumes that the important classifications of 
Association instances are carried by the "associationType" attribute, and 
that important classifications of Classification instances are determined 
by the referenced ClassificationScheme instance, and that important 
classifications of ExternalLink instances are determined by the name 
attribute (possibly renamed as extLinkType), etc.  I don't think there's 
any loss of functionality required by known use cases.



>The solution I see is quite a simple enhancement to your latest proposal. The
>proposed solution would be to add a RegistryObjectFilter with the above 
>branches
>defined.


I agree that it may make sense to allow some AssociationBranch or 
HasClassificationBranch elements on some classes other than RegistryEntry, 
but that's a decision that can be made on a case-by-case basis.

I don't think FilterQuery has to support Association instances between 
every type of class in RIM. For example, what would be the purpose of 
Association instances between AuditableEvent and ExternalIdentifier, even 
though technically they are representable in ebRIM?  If some important 
associations do exist, then lets label them and make them part of the 
ebRIM  specification. NOTE: FilterQuery does treat the important 
association from Classification to Organization (i.e. 
SubmittingOrganization) as an important association; each 
HasClassificationBranch has a SubmittingOrganizationBranch as a 
sub-element. This recognizes that Classification of a RegistryEntry can be 
done by someone other than the SubmittingOrganization that owns that 
RegistryEntry. E.g. the UserCarDealers association may classify electronic 
parts in a completely different way than does the IEEE. Also note that the 
two AssociationBranch elements do NOT have a SubmittingOrganizationBranch 
as a sub-element; this is because at one point in the past I thought we all 
agreed that all Association instances would be owned by the 
SubmittingOrganization of the sourceObject (but this assumed rule is not 
yet part of ebRIM).



>Please let the team know urgently what you think.


Unfortunately, I still think that ebRIM is seriously under-specified and is 
lacking in discipline. It's too general in that it's possible to represent 
things that don't have any basis in real world use cases, and some things 
like submitting and responsible organizations are not fully specified. So 
the Registry Services specification (ebRS), which is what implementors will 
claim conformance to, has to make some decisions that were left too 
general, or even unspecified, in ebRIM.

-- Len



>Len Gallagher wrote:
>
> > Query team,
> >
> > At last Friday's Query teleconference, I agreed to update the FilterQuery
> > proposal to incorporate decisions made during that meeting, to modify all
> > subsections of ebRS Section 8.2 to bring them into line with the revised
> > ebRIM, and to publish the whole proposal as a single revision of that
> > section of the spec.
> >
> > The complete section 8.2 is attached as a line-numbered PDF document (31
> > pages).
> >
> > Here's an overview:
> >
> > 8.2 -- FilterQuerySupport
> > Very minor edits to introduction.
> >
> > 8.2.1 -- FilterQuery
> > Minimal changes to bring attribute names into alignment with ebRIM.
> >
> > 8.2.2 -- RegistryEntryQuery
> > Created a new ExternalLinkBranch element as agreed by the team.
> > Marked the 3 alternative subelements of HasPathBranch as incomplete and
> > subject to enhancement or deletion.
> > Modified one of the examples to show XPATH syntax.
> >
> > 8.2.3 -- AuditableEventQuery
> > No changes. This section is subject to modification as the
> > AuditableEventClass in ebRIM evolves.
> >
> > 8.2.4 -- ClassificationNodeQuery
> > Deletion of the PermitsClassificationBranch as agreed by the team.
> >
> > 8.2.5 -- RegistryPackageQuery
> > No changes.
> > NOTE: The functionality of RegistryPackageQuery is all attainable via a
> > slightly longer REgistryEntryQuery. Maybe the whole section is a candidate
> > for deletion.
> >
> > 8.2.6 -- OrganizationQuery
> > Deletion of ContactFilter as agreed by the team. This section could be
> > further enhanced to support dynamic classification of organizations. That
> > enhancement would be straight-forward once decisions on
> > HasClassificationBranch are agreed.
> >
> > 8.2.7 -- ReturnRegistryEntry
> > Minor wording changes for clarity.
> >
> > 8.2.8 -- ReturnRepositoryItem
> > Significant modifications to capture ebRIM changes to now treat
> > ClassificationScheme and Package as metadata.
> > Created new element for ClassificationSchemeRepresentation.
> > Created new element for RegistryPackageElements.
> > Re-named ExtrinsicObject to ExtrinsicObjectFile to avoid conflict with
> > metadata.
> > Re-named ExternalLink to ExternalRegistryItem to avoid conflict with 
> metadata.
> >
> > 8.2.9 -- RegistryFilters
> > Minor wording changes in Semantic Rules 15, 16, 17.
> >
> > 8.2.10 -- XML Clause Constraint
> > No changes.
> >
> > -- Len
> >
> > **************************************************************
> > Len Gallagher                             LGallagher@nist.gov
> > NIST                                      Work: 301-975-3251
> > Bldg 820  Room 562                        Home: 301-424-1928
> > Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
> > **************************************************************
> >
> >   ------------------------------------------------------------------------
> >                                   Name: RS_FilterQuery_20010927.pdf
> >    RS_FilterQuery_20010927.pdf    Type: Acrobat (application/pdf)
> >                               Encoding: BASE64
>
>--
>Regards,
>Farrukh
>

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************