Bruce said:
> It seems to me these three properties are overwhlemingly used
> as simple literals. I have in fact yet to see any examples
> (notwithstanding perhaps some DC documentation) where they
> are represented as resources.
(The three properties referred to were description, date, title).
For the case of date, see my last message for an example of where we
might want to allow for a range other than Literal - though I'm not sure
I would argue very hard for it, TBH! ;-)
For description, the current DCMI definition/scription for the
dc:description property includes:
===
Definition: An account of the resource.
Comment: Description may include but is not limited to: an abstract, a
table of contents, a graphical representation, or a free-text account of
the resource.
===
Given that "comment", especially the reference to a graphical
representation (i.e. the value can be an image), I think it would be
problematic to limit the range to literals.
Also the description property (or a subproperty of it) has been used to
represent e.g. the relationship between a collection and a catalogue
i.e. the catalogue is the description of the collection.
And I think it is quite reasonable to use the dcterms:abstract property
with a document as value (e.g. where one HTML page provides the abstract
for another "full text" page)
So I think I would argue quite hard that the range of dc:description
should be something other than Literal.
> More generally, I don't like the idea of suggesting more
> complicated modeling than a) is typically used, and b) which
> is really useful.
>
> Finally, WRT to RDF, I'd say that current best practice more
> commonly uses property-subproperty relations for use cases
> where one might want to indicate further information about a
> property than property- resource. I'd much rather see encouraging:
>
> ex:abbreviatedTitle rdfs:subPropertyOf dcterms:title .
>
> ... and:
>
> <http://ex.net/1> ex:abbreviatedTitle "My Title" .
>
> ... rather than:
>
> <http://ex.net/1> dcterms:title [ ex:abbreviatedTitle
> "My Title" ] .
DCMI does have a property dcterms:alternative (silly name/URI, I know -
it was before my time!) which is a subproperty of dc:title.
===
Definition: Any form of the title used as a substitute or
alternative to the formal title of the resource.
Comment: This qualifier can include Title abbreviations as well as
translations.
===
So I don't think anyone is suggesting using the last construct you
suggest above.
IIRC, the question over the range for dc:title arose mainly through the
work on mapping the IEEE LOM standard to Dublin Core
http://dublincore.org/educationwiki/DCMIIEEELTSCTaskforce
LOM is based on a tree structure and has a small set of "datatypes" for
the values of "leaf elements", including a datatype called LangString,
described as:
> A datatype that represents one or more character strings. A LangString
value may include multiple semantically equivalent character strings,
such as translations or alternative descriptions.
So that raised the question of whether an instance of a LOM element like
LOM title using that datatype should be mapped to e.g.
(a) a single statement, referencing a single value (of type something
like "Natural Language Object"), with multiple value strings; or
(b) multiple statements, each referencing a separate value (of type
Literal), with a single value string
If (a) then the range would not be the class Literal - even in that case
I suspect it should be something narrower than Resource, but we didn't
agree exactly what!
If (b) then the range could be the class Literal - but some of the
distinctions made in LOM (e.g. two occurrences of a LOM element with a
LangString datatype) would be lost in mapping to a DC description set.
Of the three cases, I think this is the one where it's most difficult to
make the argument for a non-Literal range - though I do think that
argument can be made (probably better by someone other than me!)
Personally, I don't feel strongly either way, and I'd be happy with
either a Literal or non-Literal range for the title property - just as
long as we make a decision and we're clear about the consequences! ;-)
Pete
---
Pete Johnston
Technical Researcher, Eduserv Foundation
Web: http://www.eduserv.org.uk/foundation/people/petejohnston/
Weblog: http://efoundations.typepad.com/efoundations/
Email: [log in to unmask]
Tel: +44 (0)1225 474323
|