- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Fri, 3 Dec 2010 18:38:46 -0500
- 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 UTC