[Mulgara-dev] simple app for functional groupings

[Amit Kapoor]

Hi William,

    We have something similar for Topaz at a general level and have slightly
    different nomenclature.

On Mon, Mar 10, 2008 at 05:49:20PM -0700, William Mills wrote:
> I have a relatively simple app I want to play with in Mulgara, which is doing
> functional groupings of machines.  In it I have:
> 
> roles:      a named grouping of other roles, machine expressions, and machine
> names.

    We call this an Aggregation. It is identified by a URI. An Aggregation can
    have another Aggregation as a member (along with other 'resources').

> machine expressions:     a regexp like string used to define a list of
> hostnames, i.e. www{1-4,6}.mulgara.org whih identifies 5 hosts.

    We call these the rules that define what 'resources' are members of what
    Aggregation. We have a slightly more generalized rule definition.
    Membership can be defined explicitly by adding to a list in the Aggregation
    or based on property of the resource. For example, for PLoS, Journal is an
    aggregation and you can add an article explicitly to a journal or defined
    based on eIssn value property of the article URI. This allows the same
    article to be members of multiple journals.

    We have not modelled the rules in RDF or SWRL etc. We have a 'binary'
    syntax right now, but we are still debating various aspects of the choices
    we made here.

> machine names:                a simple machine name like www1.mulgara.org

    These are the actual underlying resource and need to be identified by a
    URI. For PLoS, for example, the underlying resource can be a article,
    issue, volume, etc.

> What is the best (if there is one)  RDF way to structure this so that I can
> easily get 

    Just for discussion sake, I will summarize that our internal debate can be
    characterized into two extreme positions:

    a. To add additional triples to assert 'membership' at insertion time of
       the resource. You can choose to do this via rules inbuilt into Mulgara.

    b. To determine membership at query time. We have gone this route and have
       found it useful for one of our requirements to limit resources based on
       journal context. Thus a user visiting the site within the context of
       'Journal A' does not see any articles that are not its members.

    One of the key reasons for us was the temporal nature of the information.
    How often do you expect your 'resources' to change? How often do you expect
    your 'rules' to change? PLoS in the long run wanted users to be able to
    define their own 'journals' and hence for us that meant a very dynamic
    environment and our choice. Unfortunately there is a slight cost in terms
    of complexity and performance.

    You might also want to take a look at POWDER as well as OAI-ORE work. Feel
    free to look at the Topaz source code at (http:/www.topazproject.org/).
    Ronald and Pradeep can provide more information so you can post either to
    this list or topaz-dev.

    regards

Amit