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