Mikael said:
> 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-3b6b8af3b
> 9273893a16037aed1b3b1ca1334e7bc
>
> 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.
Yes, I agree.
> 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).
Yes.
> 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).
Hmmm... I'd disagree slightly with that last clause, I think.
In my view the object of the dcrdf:inScheme property should still be a
set or collection of which the value is a member i.e. in this case,
ex:MikaelsSheepRegister is still a set or collection of sheep, not a
collection of register-entries or descriptions of sheep or
conceptualisations related to sheep or whatever. And I could have a VES
which is a set of people or places - or indeed of concepts.
The only difference between this proposed notion of VES and the current
DCAM notion of VES-as-Value-Type should be that
- we are now talking about a named set for which the membership is
enumerable (I think this was the key criterion in what distinguished a
VES from any class?), and
- we are replacing the instance-of-class relation (rdf:type) with an
is-member-of-set(?) relation (the dcrdf:inScheme), and
- we are not assuming that the VES (the object of dcrdf:inScheme) is a
class (though if it is, that's no problem)
Your formulation above suggests (to me!) that the VES is a set of some
other things - a set of which the value itself is not a member, but of
which some resource, of an unspecified type, related to the value, is a
member?
I guess my first concern is that we are introducing these
parallel/"shadow" sets of non-sheep/non-persons/non-places, whose
members we never want to talk about(?), when all we do want to talk
about is a named, enumerable set of sheep/persons/places (whose members
are the values referred to in the statements)? (Or maybe we _do_ want to
talk about the members of these parallel sets... More on that below)
Then this takes us right back to the point of diffficulty we had with
the ValueType-as-VES question. What is a VES really? If a set of
sheep/persons/places can't be a VES, where is the boundary between the
sets which can be VES and those which can't?
And secondly, I'm really not at all sure what the relationship is
between the sheep/person/place (the value) and this _set_ of
non-sheep/non-persons/non-places. ("A set of concepts(?) which includes
a concept(?) related in some way to(?) this resource")
And on a related note, if we provide a value URI, then that URI
identifies the sheep/person/place, which is the thing which "is inScheme
the VES". But the VES is really a set of
non-sheep/non-persons/non-places. Now, I realise the crucial difference
is between inScheme and "in the set", but that does seem rather
confusing. Also if we do have URIs for the individual things in the
set-VES (the register-entries in your example above), those things are
not the sheep/persons/places, so those URIs shouldn't be used as value
URIs....
Now then, this last point does raise an interesting point about how we
conceptualise/model VES, I think. If we really _do_ think, say, Getty
TGN as VES _is_ a set of non-places (entries, concepts, descriptions or
whatever) and _not_ a set of places, then we can model it that way.
However, if we choose that approach, it suggests to me that we want to
represent _not_ the relationship between the value (place) and the Getty
TGN as VES, but the relationship between the value (place) and a
particular entry within Getty TGN. That really is the whole point after
all: to enable a metadata consumer to tie the value to a Getty entry so
that they can navigate relations between entries in the thesaurus. So
with that approach, we should be saying something like:
report:R dc:coverage place:Paris .
place:Paris a ex:Place .
place:Paris ex:isDescribedBy TGN:Paris .
TGN:Paris a ex:TGNEntry .
TGN:Paris dcrdf:inScheme Scheme:TGN .
Scheme:TGN a dcam:VES .
(I think ex:Place and ex:TGNEntry could be blank nodes instead and the
model would still apply)
This sort of "indirection" probably is more consistent with the
"traditional" view that the Getty TGN is a set of entries or descriptors
(non-places) (and it may fit better with how people model Getty TGN in
RDF? I'm not sure about that) - but it certainly introduces rather more
complexity than we've tried to capture previously.
It might (though I'm less sure about this) also mean that the way a VES
is treated is dependent on the property and its range, I think, and some
property-VES relations would be treated differently from others e.g. for
the dc:subject property, the value really is the concept in, say, the
LCSH set of concepts, and there's no need for an intermediate node:
report:R dc:subject concept:Revolution .
concept:Revolution a ex:LCSHEntry .
concept:Revolution dcrdf:inScheme Scheme:LCSH .
Scheme:LCSH a dcam:VES .
Hmmm.
It does seem more straightforward if we just say the VES is an
enumerable set of which the value - not some related resource, but the
value itself - is a member.
Cheers
Pete
---
Pete Johnston
Technical Researcher, Eduserv Foundation
Web: http://www.eduserv.org.uk/foundation/
Email: [log in to unmask]
Tel: +44 (0)1225 474323
