DCMI discussion about replacing dcam:memberOf with skos:inScheme

Dear all,

I would like to draw your attention to a discussion on the
dc-architecture list of two proposals for using SKOS properties
to represent constructs of the DCMI Abstract Model in RDF [1]:

1. To use skos:inScheme instead of dcam:memberOf to relate a 
   value to a DCAM Vocabulary Encoding Scheme.

2. To use skos:prefLabel instead of rdf:value to relate a value
   to a DCAM Value String.

See the attached summary (below) of discussion of Proposal #1.

Specifically, the discussion of #1 has noted that the
domain of skos:inScheme was left unspecified in order to
provide the flexibility to extend a concept scheme with classes
of resource other than skos:Concept -- even though the wording

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

seems to suggest that a SKOS concept scheme is indeed intended
to be understood specifically as a set of concepts.

The DCMI community would appreciate feedback on this issue, either
on this list or on dc-architecture, as appropriate.

Tom

[1] https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0910&L=DC-ARCHITECTURE&P=802

On Tue, Oct 20, 2009 at 03:15:11PM -0400, Thomas Baker wrote:
> Date: Tue, 20 Oct 2009 15:15:11 -0400
> From: Thomas Baker <tbaker@tbaker.de>
> To: DCMI Architecture <dc-architecture@jiscmail.ac.uk>
> Subject: Proposal #1: replace dcam:memberOf with skos:inScheme
> Content-Type: text/plain; charset=us-ascii
> 
> 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 <tbaker@tbaker.de>

Received on Tuesday, 20 October 2009 19:42:54 UTC