Rachel Heery <[log in to unmask]> wrote: > By using one namespace one cannot manipulate groups of terms by means of > their identifiers alone. I think this might make managing large > collections of instance metadata over time quite onerous in that one has > no way of optimising software for DC, no 'shorthand' which will enable > software to say e.g. I do not want to index any data relating to dcq > namespace URIs. Yes, but who are we to define what "subsets" of DC software is going to accept? Furthermore, I don't think that separating these terms by namespace will make things significantly easier on the implementers. > In addition one has no information from the term URI within instance > metadata as to the relation of terms to each other (one cannot distinguish > domain specific metadata). Also seems to me less than helpful. I agree that domain-specific should be moved into a separate namespace. > I also see no downside in including a version number in namespace URI, > this does not mean one has to change version when a term is addded to a > namespace. It merely gives option of creating a new version in future if > one wishes to deprecate terms or split one term into two concepts. I > expect no-one outside software devpt community to read such URIs. > End-user's view is not of version numbers but of a 'vocabulary'. Version numbers add confusion: how do I correlate this version with the correct spec? I see no downside in not including one, we still have the option of adding one in the future, when we create a new version. > On balance i would support retaining the three namespace URIs as outlined > domain specific terms as they appear. Looks like I may be in minority of > one tho! > > Along the lines of: > > http://purl.org/dc/elements/1.1 > http://purl.org/dcq/v1 > http://purl.org/dctype/v1 > http://purl.org/dced/v1 I'd be fine with: http://purl.org/dc/elements/1.1 http://purl.org/dc/q/ or instead of "q": "qual", "qualifiers", etc. http://purl.org/dc/type/ http://purl.org/dc/ed/ How's that? -- [ Aaron Swartz | [log in to unmask] | http://www.aaronsw.com ]