This discussion is interesting as the current draft of the DC-in-RDF [1] also uses rdf:type for syntax encoding schemes, rather than rdf:datatype (e.g. see section 2.3.13.2).  I guess we have now moved on to recognising that syntax encoding schemes only apply to representations (e.g. value strings), not the value itself...  

Does this mean we are now in a position to change the draft guidelines for syntax encoding schemes from:
  <dc:date>
    <dcterms:W3CDTF>
      <rdf:value>1999-09-25T14:20+10:00</rdf:value>
    </dcterms:W3CDTF>
  </dc:date>
to this?:
  <dc:date rdf:datatype="dcterms:W3CDTF">1999-09-25T14:20+10:00</dc:date>

I'd also like to raise a related issue in the DCAM: Syntax encoding scheme URI and value string language are only available for value strings - is there a reason these are not available to rich representations?  If I have embedded two bitstreams - one a GIF with a word in English and the other a JPEG with a word in another language, I am unable to indicate the syntax encoding scheme or language for these so I don't know which is which.

I noticed this whilst having a go at making a pictorial representation of the abstract model for a tutorial I run downunder.  I have found these diagrams helpful when explaining the DCAM so they may be of interest.  I'm not sure what the policy is for attachments on this listserv, but I have attached a PDF (of the PowerPoint slides).  If that's no good, the full PowerPoint is available at [2] (though the abstract model diagrams (around about slide 58) are older versions).  

Thanx,
Douglas

[1] http://dublincore.org/documents/dcq-rdf-xml/
[2] http://www.spirit.net.au/DCANZ/DCANZ2005/Campbell%20-%20A%20Roadmap%20for%20Implementing%20Dublin%20Core.ppt

>>> [log in to unmask] 1/07/05 21:52:45 >>>
Hi Mikael,

> I wonder... As the DCAM separates syntax and vocabulary encoding 
> schemes, where the former applies to a value string, and the 
> latter to the value itself - can I use both kinds in a single
statement?

Yes, I think so.

I am pretty sure it is allowed by the DCAM.

> It really can make sense. As an example, suppose I want to 
> specify the 
> format of my resource to be HTML. The following seems reasonable:
> 
> ex:MyResource dc:format _:xxx
> _:xxx         rdf:type  dcterms:IMT
> _:xxx         rdf:value "text/html"^^<my:RFC2045-contenttype>
> _:xxx         rdf:label "HTML document"
> 
> Here dcterms:IMT is the class of Internet Media Types, used as 
> vocabulary encoding scheme. my:RFC2045-contenttype is a datatype 
> specifying the syntax of content-types according to RFC2045, used as 
> syntax encoding scheme.
> 
> It would seem to be allowed by the DCAM.

Yes, I think so, too. 

As another example, I might want to specify that an "agent" (a value of
dc:creator, say) is a person, and that their name is recorded according
to some particular set of name rules. The value (a resource) is the
person and the type of the value (vocabulary encoding scheme) is the
class of persons (foaf:Person or whatever); I provide their name as a
"value string" ("Smith, John") and specify that that string is
constructed according to name format X (syntax encoding scheme)

Actually, I'd go a step further and say that in a single statement I may
wish to supply multiple value strings associated with a single value,
and I may wish to associate a different syntax encoding scheme with each
string. So in the above example I might also provide the person's name
according to some other set of name rules and specify that that second
name is constructed according to name format Y (syntax encoding scheme)

So (it seems to me) that the DCAM supports the notion that a single
statement can refer to a single vocabulary encoding scheme and multiple
syntax encoding schemes. 

As an aside, I'd just note that these constructs are not currently
supported by all the current DCMI-recommended syntax bindings e.g. both
the HTML/XHTML and XML bindings support only a single "scheme"
specification per statement, and further they do not differentiate
vocabulary encoding schemes and syntax encoding schemes, but that is a
limitation of those bindings (as indeed we noted in the Appendices to
the DCAM).

(Personally I would like to see an XML binding for DC that does support
the full set of constructs described by the DCAM fully (or at least a
larger set of constructs than the current XML binding supports))

Pete