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

Re: Wiki page on Goals

From: Thomas Baker <tbaker@tbaker.de>
Date: Sat, 4 Dec 2010 10:41:11 -0500
To: "Young,Jeff (OR)" <jyoung@oclc.org>
Cc: Emmanuelle Bermes <manue.fig@gmail.com>, Mark van Assem <mark@cs.vu.nl>, public-xg-lld <public-xg-lld@w3.org>
Message-ID: <20101204154111.GA1072@octavius>
Hi Jeff,

On Fri, Dec 03, 2010 at 06:38:46PM -0500, Jeff Young wrote:
> 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> 

Yes, that is the intention.

> 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. 

Currently http://purl.org/dc/elements/1.1/creator, which has no range,
is on offer and can be used with literal values, but you are saying that 
it would be cleaner to have one with a literal range.  This has been 
suggested before.  However...

> 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.

Right - dcterms:subject is currently rdfs:subPropertyOf dc:subject.

The problem with a hypothetical DatatypeProperty called creatorFoo
is that we wouldn't want to say that a literal string created something.
Rather, the intention would be to say that the creator has a name,
and the name is represented by a literal string.  In other words,
creatorFoo would need to be something like a "shortcut property":
"Resource has creator X, which has foaf:name Y".

There are precedents for this -- e.g., foaf:schoolHomepage, which has a 
domain of foaf:Person, is a shortcut for "person has school, school
has homepage".

> 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.

I'm bookmarking these ideas to suggest for future discussion
in the DCMI Usage Board...

Tom

> 
> 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>
> > 
> 
> 

-- 
Thomas Baker <tbaker@tbaker.de>
Received on Saturday, 4 December 2010 15:41:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 4 December 2010 15:41:51 GMT