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