Forwarding the following reply from Aidan Hogan, who was not yet
a member of dc-architecture when he Cc'd the list...
In a nutshell, Aidan suggests:
-- DC terms are so popularly instantiated by RDF publishers
because they are lightly specified. That said, some lightweight
OWL constructs could prove useful... owl:inverseOf springs to
mind for properties of the form dct:replaces/dct:isReplacedBy.
-- If DCMI leaves the safe cove of RDFS, some difficult/interesting
questions would have to be answered.
Tom
On Sun, Feb 28, 2010 at 06:09:46PM -0000, Hogan, Aidan wrote:
> Subject: RE: [pedantic-web] Re: FOAF and dcterms:creator/dcterms:Agent
> Date: Sun, 28 Feb 2010 18:09:46 -0000
> From: "Hogan, Aidan" <[log in to unmask]>
> To: <[log in to unmask]>
> Cc: "DCMI Architecture" <[log in to unmask]>
> Sender: [log in to unmask]
> Content-Type: text/plain;
> charset="us-ascii"
>
> Hi Tom,
>
> > On Wed, Feb 24, 2010 at 05:27:19PM +0000, Antoine Zimmermann wrote:
> > > Another slight problem of owl:equivalentProperty, though arguably
> > > minor, is that it is not part of the RDF/RDFS vocabulary. So, a pure
> > > RDFS reasoner or RDFS tool would simply ignore the two implicit
> > > rdfs:subPropertyOf. There is no reason to assume that all RDFS tool
> > > support the OWL vocabulary.
> >
> > Antoine raises another point on which I would appreciate feedback
> > on DCMI's work.
> >
> > DCMI Metadata Terms [e.g., 1] are currently defined entirely
> > using RDF and RDFS. Domains and ranges were assigned to most
> > DCMI properties in 2007, as discussed in [2], but every DCMI
> > property is still declared simply to be of type rdf:Property --
> > not of type owl:DatatypeProperty, owl:ObjectProperty, or
> > owl:InverseFunctionalProperty, etc, as in FOAF [3].
> >
> > DCMI metadata terms started to be coined in 1995, two years
> > before RDF even began as a project, so much of DCMI's efforts
> > have been about evolving with the times. Though we have
> > certainly noticed the rising use of OWL for defining
> > vocabularies, nobody has ever proposed that we revisit DCMI's
> > RDF-based style for declaring terms. Indeed, Antoine's point
> > above makes me wonder whether there might in fact be good
> > reasons to continue along this current path - or, if we were to
> > start using OWL vocabulary, to preserve compatibility with RDFS
> > tools by using it only in addition to RDFS vocabulary.
> >
> > I would be very interested to hear views from members of this
> > list on this question. As always, DCMI tries to promote
> > solutions that can straightforwardly be imitated by others,
> > so the general question is whether it is still good practice to
> > declare such a vocabulary using just RDF and RDFS, or whether
> > the use of OWL significantly enhances its usability, and if so,
> > in what ways.
> >
> > I will be happy to pass any such views to DCMI lists but also
> > cordially invite anyone to engage the DCMI community directly on
> > these issues by posting to the dc-architecture mailing list
> > [4].
>
> This is another hot-topic/can-of-worms, which relates to the
> expressiveness of Web vocabularies and compliance with the requirements
> of different applications and possible adopters.
>
> One point of note: adding OWL axioms to a vocabulary will not affect
> RDFS compliance. RDFS can be applied to arbitrary RDF graphs. Similarly,
> any reasoner with RDF-based semantics (RDFS/ OWL 2 RL *rule* engine)
> should usually be applicable over any RDF graph. Similarly, OWL is
> backwards compatible with a large part of the more interesting segment
> of RDFS.
>
> With respect to the DCMI metadata terms, the first question then is
> whether or not you need OWL? My intuition would be that you don't: DC
> terms are so popularly instantiated by RDF publishers because they are
> lightly specified. That said, some lightweight OWL constructs could
> prove useful... owl:inverseOf springs to mind for properties of the form
> dct:replaces/dct:isReplacedBy.
>
> More generally, once one steps outside of pure RDFS, the argument
> becomes more broad with respect to the myriad of restrictions present in
> the different DL-based species and profiles of OWL (OWL DL, OWL Lite,
> OWL 2 RL, OWL 2 EL, OWL 2 RL, OWL 2 QL). Each has its own restrictions
> for validity with respect to a given ontology. Each has its own
> advocates and implementations and possible use-cases. Ouch.
>
> In any case, most Web vocabularies are either RDFS or OWL Full: they
> reasonably pick-and-choose the RDFS/OWL constructs they deem useful
> without too much sympathy for the DL-based restrictions (which,
> conversely, are not sympathetic to the creation of Web vocabularies).
>
> FOAF have had this problem for years I guess, with respect to trying to
> keep their vocabulary within OWL DL. Thus, they have included some OWL
> syntactic sugar to keep the vocabulary *nearly* OWL DL compliant.
> However, FOAF have encountered an ultimatum: in OWL DL, a
> datatype-property cannot be inverse-functional, and thus FOAF cannot say
> that foaf:mbox_sha1sum is inverse-functional without dropping OWL DL
> compliant. Since this definition was core to the earlier FOAF use-case
> of "smushing" (in the heady days of rampant blank-nodes) they reasonably
> decided to forgo OWL DL compliance. [I may stand corrected here Dan?]
>
> I know that Antoine has been informally thinking about how to neatly
> allow Web vocabularies to link to different versions of the vocabulary
> compliant with different profiles and tools which might fit into this
> discussion. Perhaps Antoine might elaborate?
>
> Again, I cannot offer a concrete solution or way forward. All I know is
> that if DCMI leaves the safe cove of RDFS -- and given the more formal
> nature of DCMI which will probably not allow "best-effort" OWL Full
> extension -- some difficult/interesting questions will have to answered.
>
> Cheers,
> Aidan
>
> > [1] http://triplr.org/ntriples/purl.org/dc/terms/
> > [2] http://dublincore.org/documents/2007/07/02/domain-range/
> > [3] http://triplr.org/ntriples/xmlns.com/foaf/spec/
> > [4] http://www.jiscmail.ac.uk/lists/dc-architecture.html
--
Thomas Baker <[log in to unmask]>
|