Bruce said:
> On 9/25/06, Pete Johnston <[log in to unmask]> wrote:
[snip]
> > But in the DC-XML-Min example the intent is that the fragment
> >
> > <dcxm:description
> dcxm:resourceURI="http://dublincore.org/pages/home">
> > <dc:subject>History</dc:subject>
> > </dcxm:description>
> >
> > represents a DC statement that says the resource
> has-as-subject is a resource of unspecified type, represented
> by the string "History", which in RDF would be represented by
> a blank node.
> >
>
> OK, but why this distinction? Why not just say the subject is
> in fact a string literal?
>
> > But I'm not convinced that would be sufficient, because the
> RDF/XML Property Element content generates triples with
> literal objects.
> >
> > I think we'd have to use something like
> >
> > <rdf:Description rdf:about="http://dublincore.org/pages/home">
> > <dc:subject
> rdf:parseType="Resource"><dcrdf:valueString>History</dcrdf:val
> ueString></dc:subject>
> > </rdf:Description>
> >
> > to get the blank node, but that reintroduces the child
> element that people objected to.
>
> Again, I'm not clear why the blank node is important here.
Because in at least some cases we want to make the assertion that there
is a relationship, not between a resource and a literal, but between a
resource and a second, non-literal, resource, and that second
non-literal resource may not have a URI. For the case of dc:subject, an
example would be where the object is an instance of the skos:Concept
class.
(It may even be that for the majority of DCMI properties, this - object
as URI or blank node, rather than object as literal - is the pattern
that applies. There has been discussion on this list [1] and elsewhere
[2] along the lines that this is already implicit in the human-readable
descriptions of many of DCMI's properties, and that it should be made
explicit and accessible to applications through the use of rdfs:range
assertions about those properties, and in most cases the range would be
a non-literal class. Historically there has been a good deal of
uncertainty about what the intended use of many DCMI properties is/was -
whether they should be used with literals as objects or whether they
should be used with URIs or blank nodes as objects - both patterns are
endorsed by DCMI documentation, and both patterns are in fairly
widespread use. So, the suggestion on the table at present is that, to
maintain compatibility with existing use of the DCMES properties, a new
set of URIs should be coined for the range assertions should
Anyway, whatever profile of RDF/XML is used, I think we would need a
profile of RDF/XML which includes support for blank nodes (i.e. one of
the three RDF/XML patterns I suggested in previous messages).
I guess this question comes back to the fundamental question of what we
are trying to represent, what "abstract model" (lower case) for DC
metadata we are trying to support. A couple of years ago (for better or
worse! ;-)) we embarked on trying to define/describe a model for DC
metadata, which resulted in the DCMI Abstract Model document [1] That
describes a model which is similar to the RDF/RDFS model, because it is
largely based on the RDF/RDFS model, but also differs from it, in (I
think) two (or maybe three) significant areas:
(a) the notions of "description" and "description set" as sets of
specific "statements" - which I don't think have a direct analogue in
RDF/RDFS, but would (I think) correspond to the notion of a "named
graph" or "context" which at least some RDF applications introduce (and
which I think is used in SPARQL).
(b) the notion of a "value representation" - that one or more literals
(plain or typed (including XML Literals)) may act as "representations"
of another resource (which may be a non-literal) - which is accomplished
in RDF through the use of an intermediate blank node/URI which is the
subject of another triple (using dcrdf:valuString or rdfs:seeAlso
properties) with the literal as object.
I think a third point of difference is the suggestion (which is a
proposal only at the moment) that we need to distinguish DCMI's notion
of a Vocabulary Encoding Scheme from the instance-class relationship,
but again I think that is mainly a question of deciding on another
property for that relationship and adding a triple with the intermediate
blank node/URI as subject. (I think this would also offer a way of
mapping the DCMI notion of Vocabulary Encoding Scheme to the SKOS notion
of Concept Scheme, which would faciliate the integration of DC and
SKOS).
Now there is probably an argument that trying to defining a model that
differs from RDF/RDFS was the wrong approach and we should have focused
instead on explaining that the abstract model for DC metadata is/was the
RDF model, plus RDFS plus some conventions for the use of
rdf:value/rdfs:label/rdfs:seeAlso (or some community-specific
properties), plus something like "named graphs". (I think
socially/politically this approach might have been difficult because the
DC community did and does have a terminology that differs from that of
RDF, even though I think the underlying concepts referred to are in many
cases identical.)
Or maybe that (DCAM = RDF + RDFS + some conventions + named graphs) is
more or less what we have ended up with anyway - and we are just using a
different set of labels for those same concepts.
I think Mikael Nilsson's note here [2] together with the "Expressing DC
using RDF" draft spec [3] probably provides a good summary of the
current relationship between the description model described by the DCMI
Abstract Model and RDF. (Mikael or Andy, please jump in here if I'm
omitting or mis-representing anything!)
[1] http://dublincore.org/documents/abstract-model/
[2] http://dublincore.org/documents/2006/05/29/dc-rdf-notes/
[3] http://dublincore.org/documents/2006/05/29/dc-rdf/
Cheers
Pete
|