> 1. I'm not quite sure about the intention behind the date-stamping.
> We have an issued date and modified date - is this to determine
> currency of the content or to establish versioning?
The UB specifies these. The one exception to this is the dcq:modified in
the schema header, which will be set to indicate the date the schema was
last changed. The (distributed) registry intends to use a combination of
version and date-modified to determine versioning/currency.
> I also found it curious that the link only went to the most
> recent previous
> version, eg. alternative has a hasVersion of
> #alternative-002, but not an
This is used to identify the current version of the term, not prior
> 2. Not withstanding discussions about moving to
> rdfs:Datatypes, it might
> be nice to have a scheme class pre-defined for all of the
> 15/16 elements.
> The first thing anyone who wants to add their own local
> encoding scheme
> in an Application Profile to say Title (eg. for a dataset
> naming convention)
> would be to add a TitleScheme class. It would be nice if
> this schema provided
> these constructs out of the box to hang your own encoding
> schemes off.
> Though, I guess by extension all the element refinements
> should also have a
> scheme class declared, eg. CreatedScheme, TableOfContentsScheme,
> isVersionOfScheme, etc...
> 3. Related to this, I know the IMT encoding scheme is only
> valid for the
> Format element and not the medium element refinement . Do
> we have a
> similar issue with W3CDTF - the schema makes it valid only
> for Date and
> temporal, but not any of the Date element refinements
> (created, et. al.).
> I guess this is a reflection of how the usage of W3CDTF is
> defined in the
> DC Terms documents.
> Though, looking back at the DC Qualifiers document, it wasn't
> clear whether
> an encoding scheme valid for an element is also valid for its element
> refinements - as discussed  IMT isn't intended for use in
> medium but surely
> W3CDTF is intended for use in created, modified, etc.?
I don't disagree with items 2 and 3 above, but they are out of scope with
what we are trying to accomplish here. My understanding (per Tom Baker), is
that there has been some discussion regarding these issues between Eric and
Roland. However, I don't know the details as that discussion was not
conveyed to this mailing list.
> 4. There has been some discussion about the titles for these
> schema. I
> assumed discussion around this would wait until the bigger
> issues had been
> resolved - perhaps that is now? Couldn't the titles be
> based/taken from their
> dc:source documents? eg:
> dces title: "Dublin Core Metadata Element Set, Version 1.1:
> RDF Schema"
> dces description: "This schema describes version 1.1 of the
> Dublin Core
> Metadata Element Set as an RDF vocabulary for use in RDF
> The Dublin Core metadata element set is a standard for cross-domain
> information resource description. These elements have been formally
> endorsed as the CEN Workshop Agreement CWA 13874 and as the NISO
> Standard Z39.85-2001, which was used as the basis for the
> Draft International
> Standard balloted by ISO as DIS 15836."
> [maybe we should leave out the "version 1.1" bit?]
> dcq title: "DCMI Metadata Terms: RDF Schema"
> dcq description: "This schema describes the DCMI Metadata Terms as an
> RDF vocabulary for use in RDF applications. This schema
> includes all terms
> (elements, element refinements, and encoding schemes) that
> are not part of
> the Dublin Core Metadata Element Set (which are described in
> a separate schema)."
> [though the new DCMI Metadata Terms page actually lists ALL
> metadata terms
> not just the non-15 elements and also includes the DCMI Type terms]
> dcmitype title: "DCMI Type Vocabulary: RDF Schema"
> dcmitype description: "This schema describes the DCMI Type
> Vocabulary as
> an RDF vocabulary for use in RDF applications. The DCMI Type
> provides a general, cross-domain list of approved terms that
> may be used
> as values for the Resource Type element to identify the genre
> of a resource."
> I'm thinking the descriptions need to make sense out of
> context (out of DC
> context) as an RDF application might pull these up when
> validating a scrap
> of RDF data it has just found. I wasn't sure whether to
> include stuff in the
> current titles about namespaces or providing URIs...
This would be fine with me. If there are no objections we can schedule this
change after we get the new terms installed.