W3C home > Mailing lists > Public > public-xg-lld@w3.org > December 2010

RE: Wiki page on Goals

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Fri, 3 Dec 2010 18:38:46 -0500
Message-ID: <52E301F960B30049ADEFBCCF1CCAEF590A9A389E@OAEXCH4SERVER.oa.oclc.org>
To: "Thomas Baker" <tbaker@tbaker.de>
Cc: "Emmanuelle Bermes" <manue.fig@gmail.com>, "Mark van Assem" <mark@cs.vu.nl>, "public-xg-lld" <public-xg-lld@w3.org>
I'm not an expert on RDFS, but I'm pretty sure the range setting
dcterms:creator means it can't take a literal value. This seems to be
acknowledge here:

"Thus, dc:creator will still have an unspecified range and can be used
with both literal and non-literal values, while dcterms:creator will
have a (non-literal) range of Agent."
<http://dublincore.org/documents/dc-rdf-notes/#sect-3> 

I assume this is hard to explain and enforce in a way that compromises
data usability. I think that literal values for creator (and similar
elements) are important use cases and deserve to be brought forward in a
cleaner way. Conversely, the subject property (and a few others) have
potential for linking that is being overlooked. Here is how I imagine it
for "subject":

x-dcterms:subject a owl:DatatypeProperty ;
	rdfs:subPropertyOf dc:subject .

x-dcterms:subjectRef a owl:ObjectProperty ;
	rdfs:subPropertyOf dc:subject ;
	rdfs:range skos:Concept # or some other lightweight/schematic
abstraction

The rdfs:subPropertyOf gives the dc:subject element continued reasoning
value in messy datasets.

If this was done for all elements, then something like
<http://purl.org/dc/terms/> could be migrated to an owl:Ontology. I
assume the asymmetry of subject/subjectRef vs. creator/creatorVal would
be too discouraging for upgrading dcterms in place. If dcterms was
frozen, though, and development shifted to a rebranded DC-OWL with
subjectVal/subjectRef out-of-the-box, it might not be too onerous.

Jeff

> -----Original Message-----
> From: Thomas Baker [mailto:thomasbaker49@googlemail.com] On Behalf Of
> Thomas Baker
> Sent: Friday, December 03, 2010 12:45 PM
> To: Young,Jeff (OR)
> Cc: Emmanuelle Bermes; Mark van Assem; public-xg-lld
> Subject: Re: Wiki page on Goals
> 
> Hi Jeff,
> 
> On Fri, Dec 03, 2010 at 12:27:54PM -0500, Jeff Young wrote:
> > The OWL solution would be for DC to coin owl:DatatypeProperties and
> > owl:ObjectProperties as rdfs:subPropertyOf of their existing
> > rdf:Properties. As distasteful as that is, I assume that rules-based
> > alternatives will be ignored.
> 
> DCMI has already declared http://purl.org/dc/terms/creator with
> a range of dcterms:Agent, and it is indeed a sub-property of
> http://purl.org/dc/elements/1.1/creator (the property which
> is _probably_ intended in the example below because the /1.1/
> namespace is most commonly bound to the dc: prefix).  I'd like
> to understand better what specific advantage DCMI would gain
> by declaring it as an owl:ObjectProperty as opposed to leaving
> it as an RDF property with a resource class as its range.
> 
> You are not the first person to propose this, but in order
> to progress this proposal, DCMI would need to have a clear
> understanding of the benefits, and whether the interpretation
> of existing data would be at all negatively impacted by the
> change.
> 
> Tom
> 
> >
> > Jeff
> >
> > > Another question about RELATE(existing) :
> > > relationships may exist in the data but be totally implicit. If
you
> > > make them explicit, is it a new relationship, or an existing one ?
> > > Example (very simplified) :
> > >
> > > (implicit relationship)
> > > http://example.com/book1 dc:creator "J.R.R. Tolkien"
> > > http://example.com/book2 dc:creator "J.R.R.Tolkien"
> > > http://viaf.org/viaf/95218067 foaf:name "Tolkien, J.R.R. (John
> Ronald
> > > Reuel), 1892-1973"
> > >
> > > (same relationship made explicit)
> > > http://example.com/book1 dc:creator http://viaf.org/viaf/95218067
> > > http://example.com/book2 dc:creator http://viaf.org/viaf/95218067
> > > http://viaf.org/viaf/95218067 foaf:name "Tolkien, J.R.R. (John
> Ronald
> > > Reuel), 1892-1973"
> >
> 
> --
> Thomas Baker <tbaker@tbaker.de>
> 
Received on Friday, 3 December 2010 23:49:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 3 December 2010 23:49:12 GMT