tor 2006-06-08 klockan 10:14 -0400 skrev Diane I. Hillmann:
> >Andy says:
> >
> >We have two possible ways forward on the table, which are essentially
> >
> >- to say that any 'class' can be used as a 'VES' and that any 'datatype'
> >can be used as a 'SES'
> >
> >OR
> >
> >- to say that only some 'classes' can be used as 'VESs' and that only
> >some 'datatypes' can be used as 'SESs'.

Returning to this discussion before the end of public comment...

It is appropriate at this point to mention an issue with the DCAM that
originally Alistair brought up on the DC-RDF-TASKFORCE list:

http://dublincore.org/architecturewiki/AMIssues#head-3b6b8af3b9273893a16037aed1b3b1ca1334e7bc

The issue was whether VESs are best represented as Value Types at all.
SKOS takes the position that a "Concept Scheme" are not used as the type
of a concept. Instead, a skos:inScheme property is used to point to the
Concept Scheme. The type of the concept remains skos:Concept.

Thus, the suggestion was for DCMI to similarly separate between the
notions of Value Type and VES.

In this way, a value (of the property ex:pet, for example), may well be
of the Value Type ex:Sheep. That would not imply anything about the VES.

Now, if I have a controlled vocabulary of Sheep, taken from my sheep
register, I can define the VES ex:MikaelsSheepRegister and use that as a
VES, *in parallel* with the value type ex:Sheep for the value of my
ex:pet property.

That would solve most of the issues here, and be in line with Andy's and
Diane's suggestions. 

It would require the following:

* Separation of VES and Value Type in the DCAM
* Introduction of a Value Type construct in DC-XML
* Introduction of a VES property in DC-RDF (much like skos:inScheme)

Note that the dcrdf:inScheme property (or whatever it would be called)
would NOT be limited to values of dc:subject, but would be usable for
values of all properties (i.e., essentially all resources).

Saying "X is inScheme Y" means that the resource Y is referenced in the
"controlled vocabulary" defined by Y. If Y = dcterms:TGN, we know that X
is a place or region, and it is referenced in the Getty TGN thesaurus
(which contain a number of terms, names, etc.). Thus, X is the *place*,
not the *name* of the place as it exists in the TGN. Similarly, the
value of my ex:pet property is an actual sheep, while the
ex:MikaelsSheepRegister contains the names, birth dates etc. of my sheep
(but not the sheep themselves). 

What about impact on old metadata? Most non-RDF DC metadata would not be
affected, and would continue to use VES like today.  

For old DC RDF metadata, we can have a look at some Swoogle statistics:

http://dublincore.org/architecturewiki/DCRDFTaskforce?action=AttachFile&do=get&target=dcPropertiesRanges.xls.htm

It does not seem that use of the dc vocabulary encoding schemes as Value
Types are a huge problem - most Value Types are generic (like Person,
Concept, etc.), and would thus still be correct to use. The main issue
seems to be with dc:language and dc:date.

It's still bit early to make this a proposal, but I wanted to bring up
the possibility so that it can be discussed. 


/Mikael

> 
> For what it's worth, I think the latter position makes more sense to 
> me, but that shouldn't surprise you ... ;-)
> 
> >[snip]
> >
> >I'm suggesting that the former plays havoc with both our heritage and
> >our terminology - if any class can be treated as a VES, then the class
> >of all 'Sheep' is a VES - which is pretty nonsensical.  Ditto with SES -
> >the datatype of 'integer' is a SES seems to me to be, again, pretty
> >nonsensical?  'Sheep' are not a 'controlled vocabulary' and 'integer'
> >does not define the way that a 'value string is formatted' (at least not
> >in the way that we mean formatted when we have talked about syntax
> >encoding schemes in the past).  I would argue that it is not by chance
> >that DCMI has only declared certain kinds of things as being valid SESs
> >and VESs and that it hasn't declared either dcterms:Sheep or
> >dcterms:Integer (or anything vaguely like them).  We have a heritage
> >(and I guess that the reality is that it is a library or
> >library-influenced heritage) that says that some things function as
> >controlled-vocabulary-like objects (!) and some things don't and that
> >some things are essentially rules about how to structure a 'string' and
> >some things aren't.
> 
> I think this is a good articulation of how a move in the first 
> direction noted above would be perceived.  My concern is that we take 
> care not to leave behind those who have already determined that DC is 
> useful to them (or those potentially in that category) in our desire 
> to be more acceptable to the folks desiring increased specificity.
> 
> I don't disagree that some of what's perceived as our legacy is seen 
> as a "library or library-influenced heritage." Librarians have been 
> thinking about these issues longer than anybody, and if the truth be 
> told we understood the importance and value of computers sooner than 
> most people. The fact that DC has been so widely accepted is to a 
> great extent due to the fact that it harkened back to that 
> experience. I see this legacy as more good news than bad, though it 
> does require a backpack of a certain size to carry it around.
> 
> >Note: if my view of the DCMI world is the correct one, then we will need
> >to ask the question: does the DCAM also need to explicitly acknowledge
> >'datatype' as well as SES and 'class' as well as VES?
> >
> 
> This seems reasonable to me, given my tenuous grasp of the subject. 
> To be honest, reading this stuff reminds me of my old days in college 
> when I had to read Kierkegaard for a class. I found I understood it 
> for about 10 seconds, then POOF, it was gone. Now that I'm older, it 
> takes about 7 seconds.
> 
> Diane
> 
-- 
Plus ça change, plus c'est la même chose