Re: resurrecting prov-o components design

Hi Tim, All:

I think it's important to note that in this component based approach an 
entire ontology can be built automatically. Having a whole ontology 
viewable in protege is important for review. I hope that information is 
helpful in the group making a decision.

Also, I wonder why the component approach was not taken-up the last time 
it was proposed? Was it because of the editing overhead? This may also 
help in clarifying whether this approach is taken.

I'm in  favor of any procees that helps the group rapidly iterate and 
produce a quality ontology.

On a side note, I'm impressed with the rapid iteration of the ontology 
this week. It's a good sign.

Thanks,
Paul



Timothy Lebo wrote:
> PROV-O (and -wg),
>
> As we're juggling the variety of design factors for prov-o, I'm wondering if we should revisit the components design and consider re-adopting it.
>
> Using components, we could easily produce "profiles" that utilize a variety of OWL axioms.
> We could create an OWL-RL compliant version.
> We could create a version without prov:qualified subproperties (and one with them).
> We could create a version with _only_ core constructs (and not the common relations).
>
> And each of these would be created by including the appropriate underlying subsets for the profile. That is, "prov:used a owl:ObjectProperty" is stated once and included in many profiles.
>
> Further, we can begin the very much overdue need for a collection of __concrete examples__ that provide a systematic basis for determining how "done" we are with the owl ontology.
> (This is a for loop, folks. And gives hard evidence for what we are doing wrong and right)
>
> The component design is discussed at http://www.w3.org/2011/prov/wiki/PROV_OWL_ontology_components
>
>
> The biggest challenge with adopting this approach is that PROV-O team will NOT be able to "edit" a monolithic ontology file within protege.
> But I think the total time spent thus far editing the ontology indicates that the _edit_ time is not the challenge, it's the design time that is consuming us.
>
>
> Thanks,
> Tim
>
>

Received on Friday, 24 February 2012 10:37:56 UTC