Re: Tracking Core Component use

[Len Gallagher <LGallagher@nist.gov>]

David,

What you describe below is very analogous to how published research is 
rated by university tenure and promotion committees, i.e. "how often was 
your published article referenced by other authors in their published 
articles?".

Fortunately, the ebRIM and ebRS specifications do address this potential 
requirement. It seems like the core component "need" is very much like 
asking the following:

"Given an object -- how often does it appear as the "targetObject" of an 
Association instance?"

Or more specifically -- one could submit a query that takes a given 
RegistryEntry instance (e.g. id="urn:somepath:theitem") and a given 
Organization instance (e.g. id="urn:gov:nist") and return only those 
RegistryEntry instances that reference "theitem" as the targetObject of an 
Association instance, but that are owned by an organization other than 
"nist".  The query would be:


<RegistryEntryQuery>
    <SourceAssociationBranch>
       <AssociationFilter>
          targetObject EQUAL "urn:somepath:thatitem:"
       </AssociationFilter>
    </SourceAssociationBranch>
    <SubmittingOrganizationBranch>
       id NOT_EQUAL "urn:gov:nist"
    </SubmittingOrganizationBranch>
</RegistryEntryQuery>

In words, this query says: Identify all RegistryEntry instances that are 
the "sourceObject" of an Association instance that has the RegistryEntry 
instance identified by "urn:somepath:thatitem" as the "targetObject" AND 
where the submitting organization of the "sourceObject" is NOT NIST.

Unfortunately, this query does not count the items in the result set -- but 
it does list all distinct ones. That should be sufficient.

-- Len




At 09:32 AM 9/27/01, David RR Webber - XMLGlobal wrote:
>Team,
>
>I'd like some help and thoughts here.
>
>In the course of the core component work I'm doing
>someone said 'of course the Registry can tell us which
>core components and varients are most often used,
>and that will help people choose the right ones when
>starting something new'.
>
>This is an intriguing idea.  Sorta like those download
>counts from shareware.com - but in our case it
>needs to be probably when a machine API requests
>the definition of a core component, and then given
>the vaguaries of the internet - coupled to something
>like the capabilities of a tool like Webalizer to show
>some demographics.  Otherwise Ford accessing
>just one core component a million times could
>distort the numbers.
>
>I'm not sure we have anything in the current design
>of Registry that would allow us to support this
>'most popular core components' need?
>
>Could we hook some of the existing pieces - like
>audit trail, and the API, and a Webalizer tracking
>thru the webserver - together to deliver here?  Also - we
>need to drilldown into the goals and requirement
>a bit more.  So long as we can offer up a selection
>of statistical data points - we can allow solution
>providers to tee these up to answer questions
>as needed.   That saves us having to get into
>the reporting side of this - we can leave that
>open-ended.
>
>Thanks, DW.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>

**************************************************************
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
**************************************************************