+1 on prioritization *after* we have a period of free and open brain
dump. The wiki content should assign priority to each feature eventually. (01)
John Graybeal wrote:
> I think providing prioritization in the requirements would be very helpful --
>is that viable?
>
> 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.
>
> 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.
> (02)
Now worries. We are not building anything yet. We are only gathering use
cases and requirements. (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)
+1
I suspect we agree though that we should have a prioritized roadmap of
planned functionality as a guide. (05)
> Good to have in the list, though.
>
> John
>
> 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
>>
>
>
> (06)
--
Regards,
Farrukh Najmi (07)
Web: http://www.wellfleetsoftware.com (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)
|