W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2012

Re: HPO and Gene Ontology Licenses

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Wed, 8 Aug 2012 21:52:58 -0400
Message-ID: <CAFKQJ8nJ3rR-X+PwLLciFMgZYcsfurET-LJmuxiSif06z74vGA@mail.gmail.com>
To: Peter Ansell <ansell.peter@gmail.com>
Cc: "Robinson, Peter" <peter.robinson@charite.de>, Chris Mungall <cjmungall@lbl.gov>, Michel Dumontier <michel.dumontier@gmail.com>, HCLS <public-semweb-lifesci@w3.org>, bio2rdf <bio2rdf@googlegroups.com>
On Wed, Aug 8, 2012 at 8:28 PM, Peter Ansell <ansell.peter@gmail.com> wrote:
> On 9 August 2012 00:00, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
>> We have discussed that the OBO Foundry policy is to use CC0 or CC-BY
>> and it has been put to the GO that we would like to migrate to that
>> license. I don't know the status of that discussion.
>
> Was there a discussion of the merits of CC-BY-SA as a possible license?
>
>> That said, I would be strongly discouraging of (but unable to prevent)
>> any "no-blank-node" rendering of GO ontologies, and in particular
>> would note that such a transformation would render any OWL we publish
>> unsyntactic.
>
> I have always been intrigued as to why OWL was designed to make it
> syntactically incorrect to give URIs to restrictions etc. What was the
> background behind this choice?

I don't have enough information to answer this question. The choice
was made in the first OWL working group, which I did not participate
in. However I don't really what all the fuss around blank nodes and
skolemization is tbh. I've not found them to be a problem, and I'm a
little suspicious about the technical chops of those who do.

>> Further, the OBO ID Policy has been, for the most part, been put in
>> place and we do not use hash URIs and are moving to having all OBO
>> URIs resolving to page per view. See for example
>> http://purl.obolibrary.org/obo/IAO_0000032
>
> That is a great step! Along with blank nodes and annotating resources
> with known links in the Linked Data sphere, resolvable URIs are the
> main goals of Bio2RDF.

Before there was Bio2RDF, there was Neurocommons, and we have had the
same goal all along. However none of the efforts we have seen have
done justice to serving up ontology terms, not working through what it
means to serve OWL. So I agree that Ontobee is a great step. BTW, view
source for the RDF. Ontobee adopts the design we worked early in the
Neurocommons effort, which is pretty much a direct implementation of
what was stated as a goal of the semantic web stack. If a machine does
a get on the resource, you get a document meant for machine use. If
you view it in a browser, you see something helpful.

>
>> So the Foundry is already in the process of making all of the OBO
>> available as linked ontology data. I would suggest other groups join
>> this effort rather than setting out to duplicate and add confusion by
>> having a parallel set of identifiers for the same set of entities.
>
> I think you and I have always had a difference of opinion about the
> relative benefits and difficulties of a non-unique URI Linked Data
> sphere. It is great to have a freely accepted single effort on a
> single goal, but disjoint communities need to be Free/Open to explore
> other value-added options in my opinion. Where we know another URI for
> an item Bio2RDF always attempts to refer back to it in some
> semantically useful way.

You are free to do what you want.

That said, in a background of freedom of choice I'm looking to be
effective and I've not observed there to be benefit to having multiple
URIs for a single term. Rather the opposite. TBL realized this early
on which is why the advise from the beginning was to reuse URIs.

In the context of ontologies and resources maintained by no one, or
built and forgot, I can see the merits of perhaps reforming a resource
in order to improve it. That isn't the case with the OBO Foundry. Here
you have an organization with buy-in from a lot of organizations,
funders, and biologists, with expertise in OWL and semweb tools and
deployment, and with a stated commitment to doing work that can last
and is worth lasting. So while you are free to do what you want, in my
opinion, the goals we all want want to achieve will be best done so by
collaboration towards building the best resource we can, rather than
in multiple disjoint efforts. But if you disagree, by all means: knock
yourself out.

>> In fact, there have been a number of OBO participants who prefer the
>> the current GO license precisely because it prevents this kind of
>> duplicative, confusing practice, a practice that is discouraged even
>> by the W3C standards these groups are chartered to work with.
>
> It may be useful while communities are active to synchronise efforts,
> but as soon as a community becomes inactive the locked down artifacts
> it produced are unable to be revived.

Not a problem with OBO. We are quite active if you have a look.

> In addition, if the community
> legitimately has a fundamental disagreement, then there may only be
> one possible winner if the data is not Open, which may not be the best
> thing in evolutionary terms.

I am unaware of any fundamental disagreements, only outstanding issues
that need solutions.

> Even inside of an organisation as active
> as OBO, the community around a particular ontology might become
> inactive and discourage people from either contributing suggestions,
> or worse, ignore suggestions by not responding, leading eventually to
> a completely new effort--with the huge startup costs attached to that
> process--*if* the ontology cannot be forked.

A bunch of us have worked for years trying to bring about the OBO
Foundry, which has principles designed to avoid this. While your
concerns are valid in the general case, I would again urge you to
consider how you might most effectively spend your time *in this case,
in this field, with the current situation that exists*. Do you want to
duplicate efforts of many, _just in case_,  probably reducing the
effectiveness of the whole effort, or do you want to try to join and
help make the thing more likely  to succeed in the long run?

Having the ontology forked is the worst of all outcomes. It raises
doubt about the meaning of every terms. For OBO Foundry ontologies,
the principle we're working with now is that if something better comes
along the groups collaborate.  Where that needs facilitation we've got
a board that tries to help. Is this a process that is perfect? No. But
I'll offer that in doing this we're making a lot of progress in
understanding where difficulties arise and trying to adjust policies
make such situations easier in the future.

Frankly, from a technical point of view, I don't understand the need
to "fork" rather than augment. The MIREOT work we've done has
established a pattern that makes the unit of reuse be a term rather
than a whole ontology. If another effort wants to build on (or rebuild
below) some term, they can use that term and then extend, choosing to
ignore terms they don't need.

> I would prefer that there was another method used by GO to encourage
> the use of a single definitive source, without requiring it. For
> example, one alternative may be to using trademarks to prevent
> redistribution under the same or similar names, but not preventing
> forking if it becomes necessary due to inactivity or other legitimate
> reasons that are not known at the current time.

It is not the intention of the current Foundry members to prevent
forking by legal means, only persuasion. I have told you our policy
and the status wrt GO, and the process of making that happen will
continue.

You also have a mistaken view that using the GO means you are getting
information from a single definitive source - there are many many
contributors to the GO. One of my side projects is encouraging that
steps be taken to make that clear by attributing more carefully on a
term by term basis. That'll come. You might even help if you shifted
your focus a bit from rearranging RDF to exposing unavailable
information.

And again, I don't agree that having a single definitive source for a
term is a problem. You can always define *a different term* that means
something different and become the authority for that.  Or even means
the same thing (though it is hard to imagine why you would want to -
there's plenty of remaining new work to be done without wasting time
redoing things that don't need to be redone).

> It would also be nice to have people submit their license terms to
> BioPortal, in particular, (if possible in a similar way to when OBO
> has a standard across the board of either CC0 or CC-BY/CC-BY-SA) so
> people don't have to go fishing to find them.

Submit a ticket to them. I would like if they, as an organization,
even respected the license terms of the ontologies they current serve.

> It would also be nice if  people avoided describing things as Open when their intentions are
> incompatible with the generally accepted principles of Open'ness in
> terms of Open Source [1] and Open Data [2]. Trademarking is designed
> to prevent this duplicity/confusion--which noone desires--without
> impeding on either copyright or Open/copyleft principles.

There are distinct issues that are involved with making a license for
artifacts such as ontologies and standards that are also open. Many
believe that there should be an
as-open-as-possible-without-killing-the-goose license specifically
designed for these situations. You'll find that there are issues with
reuse of W3C standards documents. That said, recall the foundry
position in advocating CC0 or CC-BY. And be aware that the only real
pushback we've had to this are those (especially Hilmar) pushing us to
keep to CC0. (warms my heart). Compare, for example, UMLS.

And please don't lecture me or the GO about open. When you have
accomplished even a small fraction of what the GO has for open come
back and we'll have a discussion.


Regards,
Alan


>
> Cheers,
>
> Peter
>
> [1] http://opensource.org/docs/osd
> [2] http://opendefinition.org/okd/
Received on Thursday, 9 August 2012 01:53:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:01:12 GMT