I think providing prioritization in the requirements would be very helpful --
is that viable? (01)
For me some of these are quite far down the priority list, so I don't want to
burn too many cycles on them yet. (02)
For example, the coming community modes of Protege (and existing ones of
SWOOP?) should be considered before too much community smarts gets built into
the repository, IMHO. (03)
Similarly, I'll be strongly hoping for basic functionality before we go very
deep into mirroring/layering of servers. The latter could be exhausting. (04)
Good to have in the list, though. (05)
John (06)
At 4:48 PM -0500 1/24/08, Farrukh Najmi wrote:
>Pat Hayes wrote:
>> At 3:41 PM -0500 1/24/08, Farrukh Najmi wrote:
>>> Dear Colleagues,
>>>
>>> It would be helpful to provide identify the requirements for an Ontology
>>> Repository.
>>> Again a requirements wiki page is needed to keep track of our
>>> requirements gathering efforts.
>>>
>>> Here is an initial list from a quick brain dump (note: Repo =
>>> Repository):
>>
>> Great, thanks for this. I have some questions.
>>
>>> * Allows authors to create ontology content and store it in a
>>> "local" repo
>>
>> 1. The local/community/root distinction is very unclear: both what it
>> means and what it is supposed to be for.
>
>Local implies a repo owned by an individual author/user. In most cases
>it should be quite hidden from the .
>
>Community could be any group of people that need to collaborate on
>ontologies on part or whole. Examples
>could be a department in a company or it could be a more broader
>community of interest (e.g. Ocean Researchers)
>
>Root is the single uber repo (may be mirrored for performance and
>scale) that mainatins the most universal ontological content
>and metadata.
>
>> 2. Does 'ontology content' mean a whole ontology or part of one? What
>> counts as a part?
>
>It could be as fine grained as a Ontology term and as coarse grained as
>a package of many related complete ontologies.
>The OOR should support any granularity.
>
>>
>>> * Allow communities to manage a shared "community" repo
>>> * Provide a "root" repo that keeps tracks of community repos and
>>> provides the most universal ontology content and metadata
>>> * Supports a [maven] like distributed model where content from
>>> "local" repo may be "deployed" to the "community" repo or the
>>> "root" repo
>>
>> 3. Why is this needed? Typical ontology content can be distributed
>> without harm, and there should be no need to keep track of 'builds'
>> and so forth as with a large Java project.
>
>No one said anything abut a build per se. However, when a quanta of
>ontological content is made more publicly accessible to a broader
>community there needs to be some level of quality control via a
>deployment process IMHO. While the deploy may be automated there needs
>to be human checks on the receiving end before the content is approved.
>This implies a requirement that I missed earlier:
>
>* Supports different life cycle states for ontological content and
>provides a process for transitioning from one state to the other in a
>controlled manner.
>Note that the notification feature would notify interested parties of
>such state changes.
>
>> At the least, we should first identify what it is that people want to
>> be able to DO with ontologies in such a framework, in order to see
>> what kind of functionality needs to be supported.
>
>+1
>
>We should have a use cases wiki page for identifying use cases. Here are
>some use cases from my past work in the ebXML RegRep Semantci Content
>Managent SC:
>
><http://www.oasis-open.org/committees/download.php/5585/useCasesAndScenarios.html>
>
>Note that above is several years old and some info may not be useful /
>relevant today.
>
>>
>>> * Allows standard and extensible metadata to be associated with
>>> Ontology elements
>>
>> 4. What is an 'ontology element'? (A single assertion? A term?)
>
>It is whatever we decide is the finest granularity for ontological
>content to address our target use cases.
>In my mind a single assertion or term would qualify.
>
>> 5. What specifies the language or notation in which it is written?
>
>Do you mean "metadata" by the "it" above?
>If so, our choices would be restricted by the standards we choose for
>metadata management.
>For example, if we choose ebXML RegRep as a metadata standard then the
>language / notation for metadata is described in XML using the schema
>defined by ebXML Registry Information Model.
>
>> 6. What counts as metadata? Is this considered part of the ontology
>> content (cf. rdf:SeeAlso and rdf:Comment) or distinct from it (say, as
>> XML markup properties)?
>
>Anything that is necessary to support discovery of ontological content
>using discovery queries.
>Cataloging is a process that harvests metadata from select content.
>
>>
>>> * Supports flexible search mechanism where domain and community
>>> specific parameterized queries may be defined for metadata based
>>> searches
>>
>> 7. Does search mean the same as query? If not, what are we searching
>> for? If so, how much inferential power should be involved in the query
>> answering process? (Warning: this is a huge tarpit, cf. the recently
>> released SPARQL W3C standard.)
>
>Search to me means a parameterized stored query whose details and syntax
>are opaque to client but whose interface is defined by a set of declared
>parameters. OpenSearch and Parameterized Stored Query feature of ebXML
>RegRep are good examples.
>
>>
>>> * Supports flexible subscription and notification feature to keep
>>> interested parties notified of changes to artifacts
>>> * Supports automatic cataloging of published artifacts
>>> * Supports automatic rule-based validation of submitted artifacts
>>
>> 8. What is an artifact?
>
>artifact = any metadata or content in an ontological Registry and Reposotory
>
>> 9. What does 'validation' mean when applied to ontologies?
>
>It means enforcing business rules expressed in a chosen syntax (e.g.
>Schematron) at the time ontological information is published or updated.
>
>
>>
>>> * Maintains change history for all artifacts in repo
>>> * Supports a set of minimal authentication mechanisms (e.g. Basic,
>>> HTTPS mutual, OpenId)
>>> * Provide fine grained role-based access control and authorization
>>> over all actions
>>> * Support seamless search over multiple repos (local + community,
>>> local + community + root, other...)
>>
>
>
>
>--
>Regards,
>Farrukh Najmi
>
>Web: http://www.wellfleetsoftware.com
>
>
>
>_________________________________________________________________
>Message Archives: http://ontolog.cim3.net/forum/oor-forum/
>Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
>Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
>Shared Files: http://ontolog.cim3.net/file/work/OOR/
>Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (07)
--
----------
John Graybeal <mailto:graybeal@xxxxxxxxx> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Initiative: http://marinemetadata.org || Shore Side Data
System: http://www.mbari.org/ssds (08)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/oor-forum/
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
Shared Files: http://ontolog.cim3.net/file/work/OOR/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (09)
|