 |
 |
Returning to the dc:type issue: tis 2006-05-23 klockan 14:47 +0200 skrev Mikael Nilsson: > > 6. I'm slightly confused when to use RDF versus DC constructs as some > > of our DC constructs overlap/clash with RDF constructs, eg. > > dc:identifier vs rdf:about (or rdf:resource), dc:type vs rdf:type, > > dc:relation vs rdfs:seeAlso, dcmitype:Text vs rdfs:Literal, etc. So > > I wondered why the proposal uses dcrdf:valueString instead of dc:title > > (or rdf:value) and rdf:type instead of dc:type? I'm guessing it's so > > we can differentiate between DC-like descriptions and construction > > relationships? > > It's several things: > > * dcrdf:valueString has range rdfs:Literal, which makes it more easily > processed than rdf:value. It's still a sub-property of rdf:value, so > it's "compatible"... > > * Similarly, rdf:type has range rdfs:Class. dc:type has range, ehh, > well, probably Class too, in the end. Maybe we should discourage the use > of dc:type in RDF completely, if it's identical to rdf:type??? Historically, dc:type has been declared as a super-property of rdf:type. The reason is mostly that dc:type has allowed string values. Now, in the new guidelines, and with a range of dc:type of Class, does this make sense? Should we simply recommend using rdf:type on all occations when encoding in RDF? I think that could be reasonable... /Mikael