Re: [Obo-format] Representing OBO synonyms in OWL - SKOS?

[Robert S. <rob...@ma...>]

  I would guess that we're months away from tooling support. I think  OWL 
1.1 discussion are drawing to a close. I don't know where the syntax wars 
are currently set. I'll make enquiries.

I must admit, I have no really strong opinions on the translation. I think 
the lexicon and type distinction is maintained, if synonums are synonyms 
and not sort of synonyms.. if the types have different extents, then surely 
they are different types ! then they deserve different labels.

A good beer argument.

I wold leave synonyms etc. as rdf annotations.....

I'll try and get Mikel to send some examples of synonyms errors out to you.

Robert.
At 17:51 07/06/2006, chris mungall wrote:

>On Jun 7, 2006, at 1:32 AM, Robert Stevens wrote:
>
>>One thing to look at are the OWL 1.1 punning proposal. This offers
>>a neat way of delivering synonums.
>
>How long before all the tooling supports this do you think?
>
>>What we did with synonyms in GO is consistent with what we
>>understood the semantics of the GO representation to be.
>>Equivalence in OWL means, well equivalence.... Classes with the
>>same extent. "ThreeSidedShape" and "ShapeWithThreeAngles".....
>
>As OWL has set-theoretic semantics you are absolutely right. However,
>GO terms represent types/universals which are a little more stringent
>than owl:classes (I don't think we can indicate this without going
>into OWL full). In the absence of ways to capture this, I'd rather
>treat synonyms, especially non-exact synonyms and the entire
>terminological aspect separately
>
>>Using RDF annotation for synnum etc. is pefectly valid. It is
>>simply not as useful.
>
>I can't point to enormously useful applications yet, but it seems
>that using ontological standards for ontologies and terminological
>standards for the terminological aspects of OBO ontologies would lead
>to more interoperability. We're careful to maintain this distinction
>with obo synonym semantics so it would be a shame to lose it
>
>>The option we chose, we largely chose because it is the most
>>useful. reasoning over our translation found lots of errors in the
>>snonym/broader/narrower side of GO.
>
>I'd be interested in seeing these!
>
>>Given the punning option this is not really a point of big discussion.
>>
>>If the "equivalence" route is at odds with the realist approach, it
>>might be that the realist approach is at fault.
>
>hmm - maybe we can chat about this over a beer sometime...
>
>>
>>Robert.At 20:34 06/06/2006, st...@in... wrote:
>>
>>>All,
>>>
>>>Quoting chris mungall <cj...@fr...>:
>>>
>>> >
>>> > The current obo->owl mapping loses synonyms in translation
>>> >
>>> > Stuart's new xslt captures synonyms by defining obo:synonym
>>> > annotation properties, as well as obo:scope to capture the synonym
>>> > terminological relation (narrower/broader)
>>>
>>>yes, the aim is to represent the OBO terminology. I can circulate
>>>the prototypical OWL file it generates.
>>>
>>> > Robert and Ulrike's proposed mapping treats synonyms as
>>>owl:classes,
>>> > and uses subClassOf in the appropriate direction for broad/narrow.
>>> > This is consistent with OWL's set-theoretic semantics, but is
>>> > slightly add odds with a treatment of GO as a realist ontology. I
>>> > would rather not place GO types on the same level as terminological
>>> > concepts.
>>>
>>>i don't think GO/OBO synonyms (as currently stated) can be treated
>>>formally.
>>>Ideally, this could work, but i wonder whether synonyms can be
>>>treated
>>>in the same way as isa and partof. Of course, i don't know the
>>>details
>>>of the proposal.
>>>
>>> > My thoughts are we should use SKOS for the terminological
>>>aspects of
>>> > GO and OBO ontologies (ie the synonyms). skos:
>>> > {broader,narrower,related} correspond nicely to existing obo
>>>synonym
>>> > categories (what is called scope in the obo docs - skos has
>>> > skos:scopeNote which is different, and may correspond to a context
>>> > qualifier in obo).
>>> >
>>> > We would continue to use rdfs:label in the owl:class as the
>>>preferred
>>> > term label. However, we could also duplicate this and have an
>>> > additional skos:prefLabel (is this necessary?)
>>> >
>>> > This scheme is essentially the same as Stuart's current scheme,
>>>only
>>> > the names of the properties are being changed.
>>>
>>>i'm not sure what skos is, but assuming it defines a namespace for
>>>relations and instances dealing with synonyms, it would not appear
>>>to be
>>>a problem. Would this scheme be maintained as well as the OBO
>>>naming scheme?
>>>I think a one-to-one translation between OBO flat file/OBO XML and
>>>OBO OWL
>>>needs to be maintained.
>>>
>>> > Concerns:
>>> >
>>> > - are there traps to be wary of that will accidentally land us
>>>in OWL
>>> > Full?
>>> >
>>> > - the mixing of the terminological may confuse some people. SKOS
>>> > would only be used for synonyms. We would of course continue to use
>>> > plain owl:classes for GO terms (types/universals),
>>>owl:subClassOf for
>>> > is_a and existential restrictions for relations (we certainly
>>> > wouldn't use skos:relatedPartOf). Perhaps this may confuse some
>>> > applications? Personally  I don't think this will be a problem, the
>>> > terminological aspects of GO and OBO Foundry ontologies are
>>>separable
>>> > from the ontological aspects.
>>> >
>>> > - Stuart, would this change make life difficult for you now your
>>> > protege owl obo plugin is maturing?
>>>
>>>The plug-in is coming along, I've just completed the GUI and the
>>>hooks
>>>to the underlying OWL model. Any changes to the OWL representation
>>>should be made soon, if possible. Changes to the
>>>relation names and instance names should cause few problems,
>>>restructuring the blank nodes and dbxreferences graph would be
>>>more work
>>>(so let's avoid that...).
>>>
>>>Stuart
>>>
>>>
>>> > Comments?
>>> > Chris
>>> >
>>> >
>>> > _______________________________________________
>>> > Obo-format mailing list
>>> > Obo...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/obo-format
>>> >
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Obo-format mailing list
>>>Obo...@li...
>>>https://lists.sourceforge.net/lists/listinfo/obo-format
>>
>