[tdwg-tag] DC: was Re: Re-organisation of TDWG Ontology: Danger silence will == acquiescence!

Bob Morris morris.bob at gmail.com
Thu May 14 15:35:06 CEST 2009


Yes, and I am trying to get my head around this in my early attempts to
OWLify MRTG. This actually brings me to an owl design question I immediately
ran into. Until the point of applying a reasoner, it is not supposed to
matter whether referenced ontologies are resolvable or not, but with
Protege4 I found it easier to import the third party ontologies that I
wanted to reference. Protege 4 resolves imports if the URI is a URL to some
RDF. This made it easier for me to see how MRTG issues should relate to,
e.g. dc issues in my desire to capture the informally stated relationships
we put in the MRTG normative document (i.e. vocabularies in
http://www.keytonature.eu/wiki/MRTG_Schema_v0.7)  I am still left with the
following design question:

Loosely, the question is: to capture an intent to re-use something like dc,
should an ontology locally retarget  the original property by restricting
its domain, or should it define a new property and declare it to be
owl:equivalentProperty to the original. For example, MRTG has an Identifier
attribute of a MediaResource that is supposed to uniquely identify the
resource.

One possibility is

<owl:DatatypeProperty rdf:about="dcterms:identifier">
        <rdfs:domain rdf:resource="#MediaResource"/>
    </owl:DatatypeProperty>

This would let MRTG instance documents really reference dcterms:identifier
and sidestep any mapping requirements in integration with resources already
described by dc. It would also prohibit a MRTG valid description of a
MediaResource have no other use of dcterms:identifier, which is probably a
Good Thing for reasoning.


Another is (note upper case I in Identifier)

<owl:DatatypeProperty rdf:about="#Identifier">
        <rdf:type rdf:resource="owl:FunctionalProperty"/>
        <owl:equivalentProperty rdf:resource=dcterms:identifier"/>
        <rdfs:domain rdf:resource="#MediaResource"/>
        <rdfs:range rdf:resource="xsd:anyURI"/>
 </owl:DatatypeProperty>

Is it easy to give a simple example of an axiom that would be consistent
with one of these and inconsistent with another?

If in fact they are logically equivalent, is one of them better than the
other on some other grounds?

Assume that dcterms is  imported and resolved.  Does  the
owl:equivalentProperty guarantee these two models must be logically
equivalent?

For purposes of this question, ignore for the moment that dcterms:identifier
actually has range xsd:Literal and is not declared a FunctionalProperty in
the 2008 dcterms rdf. Also, pretend that it has the same range type that
MRTG is after...a not entirely clear issue  in itself...

Thanks

Bob
p.s. I'm thinking that MRTG wiki needs some pages about modeling and
representation and that questions like this belong there and/or on some
related, more general, TDWG wiki... but which?


On Thu, May 14, 2009 at 8:37 AM, Roger Hyam <rogerhyam at mac.com> wrote:

>
> Bob,
>
>
> There is a difference between namespace re-use and importing of ontologies.
> When it comes to inference it depends on whether your inference engine goes
> off and pulls in the ontologies associated with the namespace or whether you
> override it in some way.
>
> For good data provenance you need a crystal ball. Only after the event do
> you know what information should have been recorded in order to enable you
> to answer that all important question that has only now occurred to you. If
> we only knew how tall the photographer was we could .....  Which version of
> which software library compiled on which architecture was used to compress
> this image? Without a crystal ball you have to record everything just incase
> and I figure the law of diminishing returns kicks in pretty quickly.
>
> Roger
>
>
>
> On 12 May 2009, at 15:28, Bob Morris wrote:
>
> Sometimes DC works and sometimes it doesn't.  See
> http://www.keytonature.eu/wiki/MRTG_Schema_v0.7 where we spent and
> continue to spend a lot of effort to sort out (in the case of multimedia
> resources) what does and doesn't.   I hope people will join that
> discussion.  At the simplest level, what we do is use DC (and other
> standards) URI's for the URI of the term we are adopting.  Some DC remains
> very vague and sloppy, even in the 2008 revision.  The current "controversy"
> on the MRTG wiki is whether too much complexity gets introduced by trying to
> provide for data provenance. To me, this is an issue very important for
> science data, but only somewhat so in the communities classically served by
> DC---the cultural artifacts community possibly being the biggest exception.
>
> Bob
>
>
> On Tue, May 12, 2009 at 10:17 AM, Roderic Page <r.page at bio.gla.ac.uk>wrote:
>
>> Dear Roger,
>> This is probably off topic (and maybe I missed something), but it really
>> worries me that much of the TDWG vocabulary is unique to TDWG. Journal
>> publishers are busy pumping out Dublin Core and PRISM (sometimes with FOAF).
>> I'm trying to link this to records nomenclators pump out. I seem to recall
>> some statement that where possible TDWG would reuse existing vocabularies,
>> but I don't see this happening. In the meantime, I'm busy mapping our
>> idiosyncratic vocabulary to that used by publishers.
>>
>> Regards
>>
>> Rod
>>
>>
>>
>>
>> On 12 May 2009, at 09:59, Roger Hyam wrote:
>>
>> Hi All,
>> I need to do some work on the Taxon Name and Taxon Concept vocabularies
>> and believe I have come up with a good way of organising the TDWG ontology
>> space (everything within http:/rs.tdwg.org/ontology).
>>
>> The following are the changes I suggest:
>>
>>
>>    - All files should be OWL DL compliant
>>    - All files should be openable in Protege 4 (I believe this is now
>>    good enough to use for editing these small ontologies)
>>    - We take a highly structured modular approach I call this the Bricks
>>    and Mortar design pattern
>>       - Some files are 'Bricks' and as such *import or reference no other
>>       files, classes or individuals*. e.g. TaxonName does not mention a
>>       higher 'Name' object in the class hierarchy.
>>       - Other files are 'Mortar'. These files import Bricks and stipulate
>>       relationships between things. Because we are using OWL it is easy to define
>>       things like the class hierarchy or the range of a property in a separate
>>       file to the file the original class or property was defined in.
>>       - This pattern gives us maximum re-usability as the same Brick
>>       could be used in different ways. It does not bind us to any one
>>       implementation of one object.
>>       - An example of the usage pattern would be to define TaxonName,
>>       TaxonConcept, Rank, NomenclaturalCode as separate bricks that don't
>>       reference each other at all then create a TCS ontology that imports these 4
>>       bricks and defines their relationships.
>>    - We move to some other method of presenting the ontologies on line -
>>    possibly the OWLDoc plug-in for Protege. This would lose us the branded look
>>    we have at the moment but would be more flexible and consistent in the long
>>    run.
>>
>>
>> As I need to do this for the TaxonName TaxonConcept vocabularies I
>> volunteer to do manage the space this year if people are happy going down
>> this route.
>>
>> From the point of view of deployed systems (the nomenclators) there may be
>> a need for a namespace change on some properties but I would review what is
>> in use and this would be trivial - if necessary at all.
>>
>> What do you think? I will take silence as acquiescence on the grounds that
>> any movement is better than none -  though I don't suppose I will get round
>> to doing anything about changes till after e-Biosphere in June.
>>
>> All the best,
>>
>> Roger
>>
>>
>> -----------------------------------------------------
>>  Roger Hyam - Project Officer WP4
>>  Pan European Species Infrastructure
>>  +44 75 90 60 80 16
>> -----------------------------------------------------
>>
>>
>>
>>
>> _______________________________________________
>> tdwg-tag mailing list
>> tdwg-tag at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>>
>>
>>    ---------------------------------------------------------
>> Roderic Page
>> Professor of Taxonomy
>> DEEB, FBLS
>> Graham Kerr Building
>> University of Glasgow
>> Glasgow G12 8QQ, UK
>>
>> Email: r.page at bio.gla.ac.uk
>> Tel: +44 141 330 4778
>> Fax: +44 141 330 2792
>> AIM: rodpage1962 at aim.com
>> Facebook: http://www.facebook.com/profile.php?id=1112517192
>> Twitter: http://twitter.com/rdmpage
>> Blog: http://iphylo.blogspot.com
>> Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> tdwg-tag mailing list
>> tdwg-tag at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>>
>>
>
>
> --
> Robert A. Morris
> Professor of Computer Science
> UMASS-Boston
> ram at cs.umb.edu
> http://bdei.cs.umb.edu/
> http://www.cs.umb.edu/~ram <http://www.cs.umb.edu/%7Eram>
> http://www.cs.umb.edu/~ram/calendar.html<http://www.cs.umb.edu/%7Eram/calendar.html>
> phone (+1)617 287 6466
> _______________________________________________
> tdwg-tag mailing list
> tdwg-tag at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>
>
> -------------------------------------------------------------
> Roger Hyam
> Roger at BiodiversityCollectionsIndex.org
> http://www.BiodiversityCollectionsIndex.org
> -------------------------------------------------------------
> Royal Botanic Garden Edinburgh
> 20A Inverleith Row, Edinburgh, EH3 5LR, UK
> Tel: +44 131 552 7171 ext 3015
> Fax: +44 131 248 2901
> http://www.rbge.org.uk/
> -------------------------------------------------------------
>
>
>
>
>


-- 
Robert A. Morris
Professor of Computer Science
UMASS-Boston
ram at cs.umb.edu
http://bdei.cs.umb.edu/
http://www.cs.umb.edu/~ram
http://www.cs.umb.edu/~ram/calendar.html
phone (+1)617 287 6466
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20090514/42b31c7c/attachment.html 


More information about the tdwg-tag mailing list