Re: OWL version of Dublin Core?

Hi Yoshio,

We use a subset of Dublin Core in our UML ontology modeling framework 
for metadata about the ontologies we and our customers build.  In order 
to ensure DL compliance, we had to add a few statements to our 
ontologies, which we're now grouping into a single ontology that we'll 
post to our site.  That's not yet done, but we would be happy to share 
what we've learned if you would like to discuss it off the list.

Having said that, there is work ongoing at DCMI to upgrade the standard, 
for example to incorporate a proposal that would  assign ranges to some 
of the terms.  The proposals are available for public comment (or were, 
at least, until early March) -- I'm sure that they would accept feedback 
at this point, even though the formal review period has ended. There are 
a number of related changes in work, including expressing Dublin Core 
using RDF.  Tom Baker, who is a director of the DCMI and co-chairs 
Semantic Web Deployment working group at W3C that I'm involved in, sent 
the email I've included below on this to the SWD list, but hopefully he 
won't mind that I share it to answer your question.

Best regards,

Elisa

>----
>
>I would like to draw the attention of this group to a Public
>Comment period, through 5 March, on a revised version of the
>DCMI Abstract Model [1] and a proposed vocabulary of domains
>and ranges for DCMI metadata terms [2].  
>
>In particular Section 5, which specifies the relationship
>of the DCMI Abstract Model to RDF [6], may be of interest.
>
>Further context about this comment period is provided in
>postings to the DC-ARCHITECTURE working group [3,4, see also
>below], where any comments should be posted and discussion
>is now taking place [5].
>
>Tom Baker
>
>[1] http://dublincore.org/documents/2007/02/05/abstract-model/
>[2] http://dublincore.org/documents/2007/02/05/domain-range/
>[3] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0702&L=dc-architecture&P=171
>[4] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0702&L=dc-architecture&P=291
>[5] http://www.jiscmail.ac.uk/lists/dc-architecture.html
>[6] http://dublincore.org/documents/2007/02/05/abstract-model/#sect-5
>
>
>
>  
>
>>> Date: Mon, 5 Feb 2007 18:32:28 +0100
>>> From: Thomas Baker <tbaker@tbaker.de>
>>> To: DCMI Architecture <dc-architecture@jiscmail.ac.uk>
>>> Subject: Public comment for revision of DCMI Abstract Model
>>> 
>>> The DCMI Abstract Model, which attained the status of DCMI
>>> Recommendation in March 2005, has been revised in light of
>>> discussion and feedback from the DCMI Architecture Working
>>> Group, the DCMI Usage Board, and the broader community.
>>> 
>>> This revised version of the Abstract Model [1] has been
>>> posted for a four-week public comment period.  The major
>>> differences between this revised version and the 2005 version
>>> [2] are summarized below.  A revised DCMI Namespace Policy
>>> [3] proposing a new DCMI namespace for Abstract Model entities
>>> has been posted for comment at the same time.
>>> 
>>> Interested members of the public are invited to post comments
>>> on these Proposed Recommendations to the DC-ARCHITECTURE
>>> mailing list [4], including "[DCAM Public Comment]" in the
>>> subject line. Public Comment will be open from 5 February
>>> through 5 March 2007.
>>> 
>>> [1] http://dublincore.org/documents/2007/02/05/abstract-model/
>>> [2] http://dublincore.org/documents/2005/03/07/abstract-model/
>>> [3] http://dublincore.org/documents/2007/02/05/dcmi-namespace/
>>> [4] http://www.jiscmail.ac.uk/lists/dc-architecture.html
>>> 
>>> 
>>> 
>>> 
>>> Changes in the DCMI Abstract Model, 2005 to 2007
>>> 
>>> --  Added a table explicitly mapping Abstract Model entities to
>>>     properties and classes of the Resource Description Framework
>>>     (RDF) and RDF Schema (RDFS).  The DCMI Abstract Model defines
>>>     a particular Description Model on the basis of RDFS semantics.
>>> 
>>> --  Added a separate Vocabulary Model specifying the types
>>>     of "terms" used in Dublin Core metadata descriptions and
>>>     including support for formal domains and ranges for properties.
>>>     The declaration of a vocabulary of classes and their use
>>>     as domains and ranges for DCMI properties is the focus of a
>>>     separate Public Comment period.
>>> 
>>> --  Changed the definition of 'vocabulary encoding scheme' --
>>>     defined in 2005 as "a class that indicates that the value of a
>>>     property is taken from a controlled vocabulary" -- to mean "an
>>>     enumerated set of resources" of which the value is a member.
>>>     (A value can be described as an instance of a class by other
>>>     means, such as by a separate statement to this effect).
>>> 
>>> --  Updated the definition of 'rich representation', adding
>>>     the notion of 'media type'.
>>> 
>>> Other editorial changes
>>> 
>>> --  Tightened the definition of 'syntax encoding scheme',
>>>     explicitly mapping the concept to the RDF Schema class
>>>     'Datatype'.
>>> 
>>> --  Tightened terminology and wordings to clarify meaning
>>>     (e.g., by consistently using phrases instead of sentences for
>>>     definitions; by referring to 'described resource' instead of
>>>     just 'resource'; by using the phrase "separate 'description'
>>>     about the 'value'" instead of a modeling entity for 'separate
>>>     description').
>>> 
>>> --  Shortened the document by removing sections describing
>>>     related issues such as 'dumb-down' (formerly Section 5),
>>>     'structured values' (formerly Appendix A), and specific
>>>     encoding guidelines (formerly Appendixes B, C, and D).
>>>     Much of this material will be provided in revised form in
>>>     more user-oriented documentation.
>>> 
>>> --  Added a table mapping current Abstract Model terminology
>>>     to the terminology in legacy DCMI "grammatical principles"
>>>     documentation (now Appendix A).
>>> 
>>> --  Permitted a value string to be associated with either
>>>     a language tag or syntax encoding scheme, or neither, but
>>>     not both.
>>> 
>>> --  Added a note to the effect that classes can be declared
>>>     explicitly or inferred from the domains and ranges of
>>>     properties.  Dropped the guideline that in DCMI metadata
>>>     descriptions, the class of the resource being described should
>>>     be indicated by the value of the Dublin Core Type property.
>>> 
>>> --  Simplified the Description Model, removing 'marked-up
>>>     text' and 'structured value string' as separate entities and
>>>     rearranging the diagram to improve readability.
>>> 
>>> --  Added placeholder URIs identifying DCMI Abstract Model
>>>     entities in a new DCMI namespace (as described in the 
>>>     revised DCMI Namespace Policy, also posted for Public
>>>     Comment).
>>> 
>>> --  Replaced QNames throughout the document with full URIs.
>>> 
>>> 
>>> 
>>> -- 
>>> Dr. Thomas Baker <tbaker@tbaker.de>
>>> Director, Specifications and Documentation
>>> Dublin Core Metadata Initiative
>>    
>>


Richard Cyganiak wrote:

>
> On 23 Apr 2007, at 12:46, Yoshio Fukushige wrote:
>
>> My current problem is that I want a transitive version of
>> http://purl.org/dc/terms/isPartOf .
>>
>> Should I use a property in other major vocabularies,
>> for example
>> http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/ 
>> part.owl#partOf
>> (I'm not sure if it is major, though)
>>
>> Or defining my own transitive property as a subPropertyOf
>> http://purl.org/dc/terms/isPartOf
>> would make more sense?
>
>
> I would recommend to define your own property and make it a  
> subproperty of dc:isPartOf. This is a common approach: Define your  
> own vocabulary with all the constraints you need, and then relate it  
> to popular vocabularies using subClassOf/subPropertyOf. This gives  
> you the best of two worlds -- hand-tailored constraints, and  
> compatibility with consumers of the popular vocabularies (provided  
> they do subclass/subproperty inference).
>
> Richard
>
>
>>
>> [1] http://dublincore.org/
>>
>> Best,
>> Yoshio Fukushige
>>
>> -- 
>> Yoshio Fukushige <fukushige.yoshio@jp.panasonic.com>
>> Network Development Center,
>> Matsushita Electric Industrial Co., Ltd.
>>
>>
>>
>>
>
>
>
>
>