2009/10/20 Thomas Baker <[log in to unmask]>

On Oct 15, 2009, at 1:25 AM, Thomas Baker wrote:
> >David Wood suggests two changes in how DCAM constructs are
> >represented in RDF [1]:
> >
> >1. Instead of using dcam:memberOf to relate a value to a
> >  DCAM Vocabulary Encoding Scheme [1, section 4.5], David
> >  suggests using skos:inScheme.

Points made about proposal #1 to date:

-- The range of skos:inScheme is skos:ConceptScheme [3].

-- The domain of skos:inScheme was left unspecified [2] in
  order to provide the flexibility to extend a concept scheme
  with classes of resource other than skos:Concept (i.e., the use
  of skos:inScheme does not imply that the subject is a concept).

-- That said, the SKOS Reference does indeed say [3]:

      "A SKOS concept scheme can be viewed as an aggregation of one
      or more SKOS concepts."

  implying that a SKOS concept scheme is intended to be
  understood as a set of SKOS concepts.  However, the wording
  "can be viewed" seems vague enough so as not to actually
  _contradict_ the notion of a skos:ConceptScheme as a set of
  things of any type (i.e., instances of classes other than
  skos:Concept).

-- Bernard elaborates on the consequences of entailments [5]:

  > #1 : Complete agreement, being aware of consequences.  If
  > the domain of skos:inScheme is open, its range is
  > skos:ConceptScheme, so using this property entails that any
  > dcam:VocabularyEncodingScheme used as the object of
  > skos:inScheme is a skos:ConceptScheme.  The following
  > logical step is to declare dcam:VocabularyEncodingScheme as
  > a subclass of skos:ConceptScheme.  And the next one is
  > asking what is specific to this subclass.  If there is no
  > specificity, dcam:VocabularyEncodingScheme could as well
  > (should?) be replaced in the abstract model by
  > skos:ConceptScheme.  Do you want to go this far in
  > entailments?

  In other words, replacing dcam:memberOf with skos:inScheme
  suggests that we also declare:

       dcam:VocabularyEncodingScheme rdfs:subClassOf skos:ConceptScheme

  and that we replace the notion of VES in DCAM with
  that of SKOS concept scheme.

-- dcam:memberOf could be declared a subproperty of skos:inScheme:

       dcam:memberOf rdfs:subClassOf skos:inScheme

My personal position, in light of the above:

-- That DCMI should declare both:

   dcam:VocabularyEncodingScheme rdfs:subClassOf skos:ConceptScheme

  and

   dcam:memberOf rdfs:subPropertyOf skos:inScheme

-- That the DCAM Description Set model [4] should be revised to
  use skos:ConceptScheme instead of (or rather in addition to)
  dcam:VocabularyEncodingScheme, underlining the equivalence of
  the two and emphasizing that a SKOS concept scheme is
  understood _not_ to be limited to SKOS concepts.

-- That DCAM should be revised to use skos:inScheme instead of
  dcam:memberOf -- _unless_ we do in fact see a significant difference
  between a SKOS concept scheme and a VES.

I would want to get some input on whether sub-property relations
is the way to do this (as opposed to, say, owl:equivalentProperty [6]).

Am I overlooking anything?

Tom

[1] http://dublincore.org/documents/dc-rdf/#sect-4
[2] http://www.w3.org/TR/skos-reference/#L2805
[3] http://www.w3.org/TR/skos-reference/#schemes
[4] http://dublincore.org/documents/abstract-model/
[5] https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0910&L=dc-architecture&P=2739
[6] http://www.w3.org/TR/owl-ref/#equivalentProperty-def

--
Thomas Baker <[log in to unmask]>