Aaron-
Thanks for the responses. 1 Follow-up thought given in context below.
----- Original Message -----
From: "Aaron Swartz" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, May 18, 2001 5:05 PM
Subject: Re: Questions regarding representation of dcq encoding in rdf
> Tim Cole <[log in to unmask]> wrote:
>
> > This allows dcq:encoding to be a specialized form of rdf:type -- with
all
> > the meaing of rdf:type PLUS additional specialized characteristics --
> > rather than simply an exact equivalent of rdf:type.
>
> I'm not aware of a dcq:encoding property, so I'm not sure quite how to
> respond. Could you provide a reference to where this property is defined?
> Ahh, I see, you are suggesting it. Hmm, I don't see the benefits...
>
> > This allows dcq:encoding to be a specialized form of rdf:type -- with
all
> > the meaing of rdf:type PLUS additional specialized characteristics --
> > rather than simply an exact equivalent of rdf:type.
>
> What would these additional meanings be?
>
> > It would facilitate
> > local community extension of dcq semantics which is allowed (or
encouraged
> > depending on how you read the current spec), since it would enable
local
> > communities to create additional semantics in their namespaces designed
to
> > be used as specific class values under dcq:encoding (rather than simply
as
> > instances of more generic rdf:type class values).
>
> I'm not sure I understand the benefit here. I think the value of rdf:type
is
> that it is well understood by RDF processors and there is a shortcut for
> creating the triple (the "typed-node" syntax).
>
I was too focused on property specializations and a single specialization
for all dcq encodings. There are already sufficient superclasses defined
in proposed rdf schema for dcq to acheive the same desired benefit (I
think). I believe the following example:
<rdf:Description>
<dc:subject>
<dcq:MESH>
<rdf:value>D08.586.682.075.400</rdf:value>
<rdfs:label>Formate Dehydrogenase</rdfs:label>
</dcq:MESH>
</dc:subject>
</rdf:Description>
could be legitimately expressed as:
<rdf:Description>
<dc:subject rdf:parseType="Resource">
<rdf:type
rdf:resource="http://dublincore.org/2000/03/13/dcq#MESH"
rdfs:subClassOf="http://dublincore.org/2000/03/13/dcq#SubjectScheme" />
<rdf:value>D08.586.682.075.400</rdf:value>
<rdfs:label>Formate Dehydrogenase</rdfs:label>
</dc:subject>
</rdf:Description>
The same 4 triples in the same relationship are produced by the second
example as the first. The second example generates one additional triple
which makes explicit the realtionship between dcq:MESH and
dcq:SubjectScheme, but this relationship is consistent (I think) with the
relationship already expressed in the rdf schema for dcq.
The desired objective of this longer form is to facilitate
community-specific extensions of dcq encodings, particularly where no rdf
schema for the community-specific namespace exists. Thus, assuming
existence and proper declaration of the additional namespace, one could
say:
<rdf:Description>
<dc:subject rdf:parseType="Resource">
<rdf:type
rdf:resource="http://foo.bar.edu/myNamespace#PACS2001"
rdfs:subClassOf="http://dublincore.org/2000/03/13/dcq#SubjectScheme" />
<rdf:value>01.30.Vv</rdf:value>
<rdfs:label>Physics literature and publications -- Book
reviews</rdfs:label>
</dc:subject>
</rdf:Description>
I think this conveys clearly and unambigously that PACS2001 (2001 Physics
and Astronomy Classification System) is being used as a community-specific
encoding extension for dc:subject.
Of course if the community included an rdf schema for its own namespace, it
could revert to the shorthand "typed-node" syntax and make the tie between
community-specific subject encodings and dcq:SubjectScheme in the rdf
schema instead of in the document instances. It's just nice to know that
the explicit option is also available. Assuming of course this means what
I think it means.
Tim Cole
University Library
University of Illinois at Urbana-Champaign
|