database backend

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

database backend

Rocky Dunlap
Hi,

Is anyone currently working on a database backend for Protege 4?  If
not, has anyone thought about how it would be architected?

Thanks!
Rocky
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: database backend

Nick Drummond
The answer to the first question is "not yet".

The answer to the second is:
I think the experiences with developing a DB backend to p3.x will inform the design and architecture.
I don't believe we have any official plans currently for this issue.
There are also alternative plans for covering some of the use-cases for having a DB (such as multi-user support).

Nick

On Tue, Jul 29, 2008 at 5:39 AM, Rocky Dunlap <[hidden email]> wrote:
Hi,

Is anyone currently working on a database backend for Protege 4?  If
not, has anyone thought about how it would be architected?

Thanks!
Rocky
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: database backend

Rocky Dunlap
Actually, I was going down the "multi-user" support route myself.

Can you give my an idea of what is already in the works already along
these lines?

To give you a bit of background, I'm working on a project in the
climate modeling domain and we have a serious need for tools to
support collaborative development of OWL ontologies.  You could think
of it as source control for ontologies, but it's much more interesting
because you are dealing with logical consequences of changing axioms,
defining what a transaction is, etc.

My initial plan was to add a new type of Parser to the OWL API to
support a relational DB, then add some extra-logical annotations to
manage things like transaction sets, users, dates and times, versions,
etc.  Once that was done in the abstract, a Protege plugin would allow
users to commit changes, download new versions, and see diffs via the
interface.

Do you know of anyone working along these lines?

Rocky

On Tue, Jul 29, 2008 at 7:57 AM, Nick Drummond
<[hidden email]> wrote:

> The answer to the first question is "not yet".
> The answer to the second is:
> I think the experiences with developing a DB backend to p3.x will inform the
> design and architecture.
> I don't believe we have any official plans currently for this issue.
> There are also alternative plans for covering some of the use-cases for
> having a DB (such as multi-user support).
> Nick
> On Tue, Jul 29, 2008 at 5:39 AM, Rocky Dunlap <[hidden email]> wrote:
>>
>> Hi,
>>
>> Is anyone currently working on a database backend for Protege 4?  If
>> not, has anyone thought about how it would be architected?
>>
>> Thanks!
>> Rocky
>> _______________________________________________
>> p4-feedback mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>
>
> _______________________________________________
> p4-feedback mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>
>
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: database backend

Jennifer Vendetti
Administrator
Rocky,

Rocky Dunlap wrote:
> To give you a bit of background, I'm working on a project in the climate modeling domain and we have a serious need for tools to support collaborative development of OWL ontologies.

I am wondering if you have looked at Collaborative Protege [1]?  It's a
Protege extension that supports collaborative ontology development.  The
extension was developed for the Protege 3.x series and has not yet been
migrated to Protege 4, but we have plans to do so.

Jennifer

[1] http://protege.stanford.edu/doc/collab-protege/
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: database backend

Timothy Redmond
In reply to this post by Rocky Dunlap

First of all, the core obstacle for  this work is building a database  
backend for  the owl api.  Interestingly there  was another query  
about this on the protege owl mailing list.  [1] was my answer at that  
time.  Since that time  we have done an epsilon of additional  work.  
I have thought about  option #2 (a non-rdf based backend that does  
both the tbox  and the abox) and  started  the proposal [2].  This  
last is  in a very early stage and may not be generally understandable  
yet.

We  still have not  started this work but  we recognize the importance  
of this  issue.

-Timothy


[1] https://mailman.stanford.edu/pipermail/protege-owl/2008-July/007768.html
[2] https://bmir-gforge.stanford.edu/gf/project/owleditor/wiki/?pagename=DatabaseDesignIdea


On Jul 28, 2008, at 9:39 PM, Rocky Dunlap wrote:

> Hi,
>
> Is anyone currently working on a database backend for Protege 4?  If
> not, has anyone thought about how it would be architected?
>
> Thanks!
> Rocky
> _______________________________________________
> p4-feedback mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/p4-feedback

_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: database backend

Timothy Redmond
In reply to this post by Rocky Dunlap

To give you a bit of background, I'm working on a project in the
climate modeling domain and we have a serious need for tools to
support collaborative development of OWL ontologies.  You could think
of it as source control for ontologies, but it's much more interesting
because you are dealing with logical consequences of changing axioms,
defining what a transaction is, etc.

There has been some work in this area.  First we have a version of web protege  that is in very early stages of development.  This already has collaborative features and will allow multiple users to edit a common ontology through web browsers.  We are not yet using the owl api in this work but we are thinking of moving in the Protege  4 direction.

In addition, we have been doing a significant amount of thinking about the design of a source-control/ontology server  [1] approach.  We hope  that this will support both a source control system where updates  are less common (once a day) and a owl api client server system where updates are  very common (once every five seconds).  No development work has been done yet.  But I am hopeful that the simplicity of this approach will allow rapid development of a functioning service.  Design  and  development of this service will start very soon - we have a contract where this service is a requirement.


My initial plan was to add a new type of Parser to the OWL API to
support a relational DB, then add some extra-logical annotations to
manage things like transaction sets, users, dates and times, versions,
etc.  Once that was done in the abstract, a Protege plugin would allow
users to commit changes, download new versions, and see diffs via the
interface.

If by this you mean  several owl api implementations based on a single database then I suspect that this would have to be done very carefully.  Perhaps the proposal  in [2] could be made to work??

-Timothy



On Jul 29, 2008, at 10:39 AM, Rocky Dunlap wrote:

Actually, I was going down the "multi-user" support route myself.

Can you give my an idea of what is already in the works already along
these lines?

To give you a bit of background, I'm working on a project in the
climate modeling domain and we have a serious need for tools to
support collaborative development of OWL ontologies.  You could think
of it as source control for ontologies, but it's much more interesting
because you are dealing with logical consequences of changing axioms,
defining what a transaction is, etc.

My initial plan was to add a new type of Parser to the OWL API to
support a relational DB, then add some extra-logical annotations to
manage things like transaction sets, users, dates and times, versions,
etc.  Once that was done in the abstract, a Protege plugin would allow
users to commit changes, download new versions, and see diffs via the
interface.

Do you know of anyone working along these lines?

Rocky

On Tue, Jul 29, 2008 at 7:57 AM, Nick Drummond
<[hidden email]> wrote:
The answer to the first question is "not yet".
The answer to the second is:
I think the experiences with developing a DB backend to p3.x will inform the
design and architecture.
I don't believe we have any official plans currently for this issue.
There are also alternative plans for covering some of the use-cases for
having a DB (such as multi-user support).
Nick
On Tue, Jul 29, 2008 at 5:39 AM, Rocky Dunlap <[hidden email]> wrote:

Hi,

Is anyone currently working on a database backend for Protege 4?  If
not, has anyone thought about how it would be architected?

Thanks!
Rocky
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: database backend

Matthew Horridge
Hi Rocky,

I think that one thing to keep in mind is that the issue of a "multi-
user" system, version control, client server or check-in/check-out  
system, is separate from whether or not a database back end is a  
necessary feature.  I don't think it is wise to confuse these issues.

Cheers,

Matthew


On 31 Jul 2008, at 01:38, Timothy Redmond wrote:

>
>> To give you a bit of background, I'm working on a project in the
>> climate modeling domain and we have a serious need for tools to
>> support collaborative development of OWL ontologies.  You could think
>> of it as source control for ontologies, but it's much more  
>> interesting
>> because you are dealing with logical consequences of changing axioms,
>> defining what a transaction is, etc.
>
> There has been some work in this area.  First we have a version of  
> web protege  that is in very early stages of development.  This  
> already has collaborative features and will allow multiple users to  
> edit a common ontology through web browsers.  We are not yet using  
> the owl api in this work but we are thinking of moving in the  
> Protege  4 direction.
>
> In addition, we have been doing a significant amount of thinking  
> about the design of a source-control/ontology server  [1] approach.  
> We hope  that this will support both a source control system where  
> updates  are less common (once a day) and a owl api client server  
> system where updates are  very common (once every five seconds).  No  
> development work has been done yet.  But I am hopeful that the  
> simplicity of this approach will allow rapid development of a  
> functioning service.  Design  and  development of this service will  
> start very soon - we have a contract where this service is a  
> requirement.
>
>
>> My initial plan was to add a new type of Parser to the OWL API to
>> support a relational DB, then add some extra-logical annotations to
>> manage things like transaction sets, users, dates and times,  
>> versions,
>> etc.  Once that was done in the abstract, a Protege plugin would  
>> allow
>> users to commit changes, download new versions, and see diffs via the
>> interface.
>
> If by this you mean  several owl api implementations based on a  
> single database then I suspect that this would have to be done very  
> carefully.  Perhaps the proposal  in [2] could be made to work??
>
> -Timothy
>
>
> [1] https://bmir-gforge.stanford.edu/gf/project/owleditor/wiki/?pagename=ClientServerDesignIdea
> [2] https://bmir-gforge.stanford.edu/gf/project/owleditor/wiki/?pagename=DatabaseDesignIdea
>
> On Jul 29, 2008, at 10:39 AM, Rocky Dunlap wrote:
>
>> Actually, I was going down the "multi-user" support route myself.
>>
>> Can you give my an idea of what is already in the works already along
>> these lines?
>>
>> To give you a bit of background, I'm working on a project in the
>> climate modeling domain and we have a serious need for tools to
>> support collaborative development of OWL ontologies.  You could think
>> of it as source control for ontologies, but it's much more  
>> interesting
>> because you are dealing with logical consequences of changing axioms,
>> defining what a transaction is, etc.
>>
>> My initial plan was to add a new type of Parser to the OWL API to
>> support a relational DB, then add some extra-logical annotations to
>> manage things like transaction sets, users, dates and times,  
>> versions,
>> etc.  Once that was done in the abstract, a Protege plugin would  
>> allow
>> users to commit changes, download new versions, and see diffs via the
>> interface.
>>
>> Do you know of anyone working along these lines?
>>
>> Rocky
>>
>> On Tue, Jul 29, 2008 at 7:57 AM, Nick Drummond
>> <[hidden email]> wrote:
>>> The answer to the first question is "not yet".
>>> The answer to the second is:
>>> I think the experiences with developing a DB backend to p3.x will  
>>> inform the
>>> design and architecture.
>>> I don't believe we have any official plans currently for this issue.
>>> There are also alternative plans for covering some of the use-
>>> cases for
>>> having a DB (such as multi-user support).
>>> Nick
>>> On Tue, Jul 29, 2008 at 5:39 AM, Rocky Dunlap  
>>> <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Is anyone currently working on a database backend for Protege 4?  
>>>> If
>>>> not, has anyone thought about how it would be architected?
>>>>
>>>> Thanks!
>>>> Rocky
>>>> _______________________________________________
>>>> p4-feedback mailing list
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>>>
>>>
>>> _______________________________________________
>>> p4-feedback mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>>>
>>>
>> _______________________________________________
>> p4-feedback mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>
> _______________________________________________
> p4-feedback mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/p4-feedback

_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

client/server Protege

samsontu
In reply to this post by Timothy Redmond
Hi,

In the design of the database backend and client/server Protege, I'd like to emphasize the importance of dealing with imported ontologies/knowledge bases from the start.

One of the foremost problems with the Protege 3.x is that the loaded ontology/KB is not updated when its imported ontology/KB changes. In the current client/server Protege, it means that you have to shut down and restart the server for the changes to be propagated. This is one reason that I hardly ever use the client/server Protege.

I hope you'll take into account another use case for client/server Protege. The application that connects with the server may not be a Protege client, but some application that needs to query and retrieve specific parts of the ontology/knowledge base without making changes to it. For these applications, loading the entire ontology (e.g., SNOMED CT) in the client is sometimes not an option.

Thank you.

With best regards,
Samson Tu


Timothy Redmond wrote:

To give you a bit of background, I'm working on a project in the
climate modeling domain and we have a serious need for tools to
support collaborative development of OWL ontologies.  You could think
of it as source control for ontologies, but it's much more interesting
because you are dealing with logical consequences of changing axioms,
defining what a transaction is, etc.

There has been some work in this area.  First we have a version of web protege  that is in very early stages of development.  This already has collaborative features and will allow multiple users to edit a common ontology through web browsers.  We are not yet using the owl api in this work but we are thinking of moving in the Protege  4 direction.

In addition, we have been doing a significant amount of thinking about the design of a source-control/ontology server  [1] approach.  We hope  that this will support both a source control system where updates  are less common (once a day) and a owl api client server system where updates are  very common (once every five seconds).  No development work has been done yet.  But I am hopeful that the simplicity of this approach will allow rapid development of a functioning service.  Design  and  development of this service will start very soon - we have a contract where this service is a requirement.


My initial plan was to add a new type of Parser to the OWL API to
support a relational DB, then add some extra-logical annotations to
manage things like transaction sets, users, dates and times, versions,
etc.  Once that was done in the abstract, a Protege plugin would allow
users to commit changes, download new versions, and see diffs via the
interface.

If by this you mean  several owl api implementations based on a single database then I suspect that this would have to be done very carefully.  Perhaps the proposal  in [2] could be made to work??

-Timothy



On Jul 29, 2008, at 10:39 AM, Rocky Dunlap wrote:

Actually, I was going down the "multi-user" support route myself.

Can you give my an idea of what is already in the works already along
these lines?

To give you a bit of background, I'm working on a project in the
climate modeling domain and we have a serious need for tools to
support collaborative development of OWL ontologies.  You could think
of it as source control for ontologies, but it's much more interesting
because you are dealing with logical consequences of changing axioms,
defining what a transaction is, etc.

My initial plan was to add a new type of Parser to the OWL API to
support a relational DB, then add some extra-logical annotations to
manage things like transaction sets, users, dates and times, versions,
etc.  Once that was done in the abstract, a Protege plugin would allow
users to commit changes, download new versions, and see diffs via the
interface.

Do you know of anyone working along these lines?

Rocky

On Tue, Jul 29, 2008 at 7:57 AM, Nick Drummond
<[hidden email]> wrote:
The answer to the first question is "not yet".
The answer to the second is:
I think the experiences with developing a DB backend to p3.x will inform the
design and architecture.
I don't believe we have any official plans currently for this issue.
There are also alternative plans for covering some of the use-cases for
having a DB (such as multi-user support).
Nick
On Tue, Jul 29, 2008 at 5:39 AM, Rocky Dunlap <[hidden email]> wrote:

Hi,

Is anyone currently working on a database backend for Protege 4?  If
not, has anyone thought about how it would be architected?

Thanks!
Rocky
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback


_______________________________________________ p4-feedback mailing list [hidden email] https://mailman.stanford.edu/mailman/listinfo/p4-feedback

-- 
---------
Samson Tu                                   email: [hidden email] 
Senior Research Scientist                   web: www.stanford.edu/~swt/
Center for Biomedical Informatics Research  phone: 1-650-725-3391
Stanford University                         fax: 1-650-725-7944




_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback
Reply | Threaded
Open this post in threaded view
|

Re: database backend

Rocky Dunlap
In reply to this post by Matthew Horridge
Yes, I agree completely with this.  There is a clear separate of
concerns between the storage mechanism (be it a DB or file-based, etc)
and an ontology version control system.  I guess I was just thinking a
bit ahead to how an implementation might look.  To provide a
check-in/check-out capability at the level of individual axioms, it
would likely be much more elegant to use a DB where an axiom
corresponds (more or less) to a row in a table (a la Timothy's
DatabaseDesignIdea
https://bmir-gforge.stanford.edu/gf/project/owleditor/wiki/?pagename=DatabaseDesignIdea).
 That being said, there is no conceptual reason why the storage system
would have to be database.

I would like to emphasize a similar point--namely, that an ontology
version control mechanism should not be tied directly to a particular
tool, either.  While it may be tempting to immediately dive into the
Protege source code and add support for multiple users and versioning,
it seems that defining a general API for ontology version control
should be the first step.  I envision a layer which sits on top of the
OWL API, but is completely independent of any particular tool or
visualization mechanism (although it may still involve "client" and
"server" components).  This would allow arbitrary programs, for
example, to be clients that offer changes to the ontology.  This would
also allow users to collaborate on an ontology even if they are using
two completely different tools.  I have a feeling you all might
already be going in this direction because you use the term "ontology
server" and not "Protege server."

What would be in this "ontology versioning" layer?  Here are some
brainstorming ideas...

-- some concept of a "user" or "change agent"
-- a way to "check out" all of the axioms in an ontology (e.g., the "trunk")
-- a way to tag the current state of the ontology, or perhaps create a branch
-- a way to "check out" the axioms in a certain tag or branch
-- transaction management (e.g., you want to submit an entire
collection of axioms as a single unit)
-- merging and conflict resolution  (including defining what a
"conflict" is and algorithms for "resolution")
-- doing ontology diffs (could include explicit or implicit diffs
[with the help of a reasoner])

One use case I would like to emphasize is the need for users to work
independently on a portion of the ontology and then submit changes at
a later time--and even then, the user may choose to only submit a
subset of the changes back to the server.  This implies a mechanism by
which the user can choose which axioms should actually be committed
and which should stay in the local ontology "sandbox."

I've only done some preliminary thinking along these lines, so feel
free to give plenty of critical feedback if these ideas are crazy....

Rocky


On Thu, Jul 31, 2008 at 1:55 AM, Matthew Horridge
<[hidden email]> wrote:

> Hi Rocky,
>
> I think that one thing to keep in mind is that the issue of a "multi-
> user" system, version control, client server or check-in/check-out
> system, is separate from whether or not a database back end is a
> necessary feature.  I don't think it is wise to confuse these issues.
>
> Cheers,
>
> Matthew
>
>
> On 31 Jul 2008, at 01:38, Timothy Redmond wrote:
>
>>
>>> To give you a bit of background, I'm working on a project in the
>>> climate modeling domain and we have a serious need for tools to
>>> support collaborative development of OWL ontologies.  You could think
>>> of it as source control for ontologies, but it's much more
>>> interesting
>>> because you are dealing with logical consequences of changing axioms,
>>> defining what a transaction is, etc.
>>
>> There has been some work in this area.  First we have a version of
>> web protege  that is in very early stages of development.  This
>> already has collaborative features and will allow multiple users to
>> edit a common ontology through web browsers.  We are not yet using
>> the owl api in this work but we are thinking of moving in the
>> Protege  4 direction.
>>
>> In addition, we have been doing a significant amount of thinking
>> about the design of a source-control/ontology server  [1] approach.
>> We hope  that this will support both a source control system where
>> updates  are less common (once a day) and a owl api client server
>> system where updates are  very common (once every five seconds).  No
>> development work has been done yet.  But I am hopeful that the
>> simplicity of this approach will allow rapid development of a
>> functioning service.  Design  and  development of this service will
>> start very soon - we have a contract where this service is a
>> requirement.
>>
>>
>>> My initial plan was to add a new type of Parser to the OWL API to
>>> support a relational DB, then add some extra-logical annotations to
>>> manage things like transaction sets, users, dates and times,
>>> versions,
>>> etc.  Once that was done in the abstract, a Protege plugin would
>>> allow
>>> users to commit changes, download new versions, and see diffs via the
>>> interface.
>>
>> If by this you mean  several owl api implementations based on a
>> single database then I suspect that this would have to be done very
>> carefully.  Perhaps the proposal  in [2] could be made to work??
>>
>> -Timothy
>>
>>
>> [1] https://bmir-gforge.stanford.edu/gf/project/owleditor/wiki/?pagename=ClientServerDesignIdea
>> [2] https://bmir-gforge.stanford.edu/gf/project/owleditor/wiki/?pagename=DatabaseDesignIdea
>>
>> On Jul 29, 2008, at 10:39 AM, Rocky Dunlap wrote:
>>
>>> Actually, I was going down the "multi-user" support route myself.
>>>
>>> Can you give my an idea of what is already in the works already along
>>> these lines?
>>>
>>> To give you a bit of background, I'm working on a project in the
>>> climate modeling domain and we have a serious need for tools to
>>> support collaborative development of OWL ontologies.  You could think
>>> of it as source control for ontologies, but it's much more
>>> interesting
>>> because you are dealing with logical consequences of changing axioms,
>>> defining what a transaction is, etc.
>>>
>>> My initial plan was to add a new type of Parser to the OWL API to
>>> support a relational DB, then add some extra-logical annotations to
>>> manage things like transaction sets, users, dates and times,
>>> versions,
>>> etc.  Once that was done in the abstract, a Protege plugin would
>>> allow
>>> users to commit changes, download new versions, and see diffs via the
>>> interface.
>>>
>>> Do you know of anyone working along these lines?
>>>
>>> Rocky
>>>
>>> On Tue, Jul 29, 2008 at 7:57 AM, Nick Drummond
>>> <[hidden email]> wrote:
>>>> The answer to the first question is "not yet".
>>>> The answer to the second is:
>>>> I think the experiences with developing a DB backend to p3.x will
>>>> inform the
>>>> design and architecture.
>>>> I don't believe we have any official plans currently for this issue.
>>>> There are also alternative plans for covering some of the use-
>>>> cases for
>>>> having a DB (such as multi-user support).
>>>> Nick
>>>> On Tue, Jul 29, 2008 at 5:39 AM, Rocky Dunlap
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Is anyone currently working on a database backend for Protege 4?
>>>>> If
>>>>> not, has anyone thought about how it would be architected?
>>>>>
>>>>> Thanks!
>>>>> Rocky
>>>>> _______________________________________________
>>>>> p4-feedback mailing list
>>>>> [hidden email]
>>>>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>>>>
>>>>
>>>> _______________________________________________
>>>> p4-feedback mailing list
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>>>>
>>>>
>>> _______________________________________________
>>> p4-feedback mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>>
>> _______________________________________________
>> p4-feedback mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>
> _______________________________________________
> p4-feedback mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/p4-feedback
>
_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback