>
> In fact I used one of your (with Andy Powell)'s DC-in-XML examples as
> a test case for this from
> http://dublincore.org/documents/2002/09/09/dc-xml-guidelines/
> I took example 5.3 and re-encoded it in rdf/xml with datatypes for a
> rather similar look:
I've said that before - maybe not explicitly enough:
Without a given literal to value map the datatype encoding style
produces a serious problem to dc-dumbdown.
A dc:subject content 061(40) in my view is not to be
recommended as a dumbdown from
dc:subject scheme="UDC" content="061(40)".
This is NOT a syntax issue, as you seem to imply.
The xml guideline suffers from the same problem.
rs
>
>
> <?xml version="1.0"?>
> <!DOCTYPE rdf:RDF [
> <!ENTITY dcterms 'http://purl.org/dc/terms/'>
> ]>
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:dc="http://purl.org/dc/elements/1.1/"
> xmlns:dcterms="http://purl.org/dc/terms/">
>
> <rdf:Description rdf:about="http://www.ukoln.ac.uk/">
>
> <dc:title>
> UKOLN
> </dc:title>
> <dcterms:alternative>
> UK Office for Library and Information Networking
> </dcterms:alternative>
> <dc:subject>
> national centre, network information support, library
> community, awareness, research, information services,public
> library networking, bibliographic management, distributed
> library systems, metadata, resource discovery,
> conferences,lectures, workshops
> </dc:subject>
> <dc:subject rdf:datatype="&dcterms;DDC">
> 062
> </dc:subject>
> <dc:subject rdf:datatype="&dcterms;UDC">
> 061(410)
> </dc:subject>
> <dc:description>
> UKOLN is a national focus of expertise in digital information
> management. It provides policy, research and awareness services
> to the UK library, information and cultural heritage communities.
> UKOLN is based at the University of Bath.
> </dc:description>
> <dc:description xml:lang="fr">
> UKOLN est un centre national d'expertise dans la gestion de l'information
> digitale.
> </dc:description>
> <dc:publisher>
> UKOLN, University of Bath
> </dc:publisher>
> <dcterms:isPartOf rdf:datatype="&dcterms;URI">
> http://www.bath.ac.uk/
> </dcterms:isPartOf>
> <dcterms:modified rdf:datatype="&dcterms;W3CDTF">
> 2001-07-18
> </dcterms:modified>
> <dc:format rdf:datatype="&dcterms;IMT">
> text/html
> </dc:format>
> <dcterms:extent>
> 14 Kbytes
> </dcterms:extent>
>
> </rdf:Description>
> </rdf:RDF>
>
>
> The above should pass an updated rdf/xml parser, such as
> mine, Raptor http://www.redland.opensource.ac.uk/raptor/ - plug ;)
>
>
> > At the moment, encoding schemes are defined as RDF Classes and an
> > individual "value" within a scheme is a resource of that type. So e.g.
> >
> > In 2.3.9 of [DCQ-RDF-XML], the examples of MESH include
> >
> > dcterms:MESH rdf:type rdfs:Class .
> >
> > _:a dc:subject _:x .
> > _:x rdf:type dcterms:MESH .
> > _:x rdf:value "D08.586.682.075.400" .
> > _:x rdfs:label "Formate Dehydrogenases" .
> >
> > And 2.3.13 of [DCQ-RDF-XML], the examples of W3C-DTF include
> >
> > dcterms:W3CDTF rdf:type rdfs:Class .
> >
> > _:b dc:date _:y .
> > _:y rdf:type dcterms:W3CDTF .
> > _:y rdf:value "1999-09-25T14:20+10:00" .
> >
> > My question arose because several of the examples in the RDF Primer show
> > dates modelled as typed literals. So (I think?) it would be possible
> > (though I don't know whether it's desirable, which is really what I'm
> > asking here!) to adopt an alternative convention where dcterms:W3CDTF is
> > declared/defined as of type rdfs:Datatype (instead of rdfs:Class):
> >
> > dcterms:W3CDTF rdf:type rdfs:Datatype .
> >
> > _:b dc:date "1999-09-25T14:20+10:00"^^dcterms:W3CDTF .
>
> Yes, but the syntax isn't quite that in N-Triples (here qnames are
> being used, so the above is N3 with datatypes) and should be:
>
> _:b <http://purl.org/dc/elements/1.1/date> "1999-09-25T14:20+10:00"^^<http://purl.org/dc/terms/W3CDTF> .
>
>
> > I can see that in the MESH case, an individual "value" is a
> > resource/object with multiple attributes (i.e. the "Heading" and the
> > "Tree Number" - and presumably an associated definition/scope note could
> > be included) and that "value object" can't be modelled fully as a
> > literal.
> >
> > And I can see that for encoding schemes which are "controlled
> > vocabularies" or some form of "enumerated lists" of values, the
> > rdfs:Class-based approach allows you to assign a URI to the resource
> > representing each "value" in the list/vocabulary and then those
> > resources can be referenced from multiple instances (using rdfs:resource
> > in XML), e.g. something like:
> >
> > http://www.nlm.nih.gov/mesh/D08.586.682.075.400 rdf:type dcterms:MESH .
> > http://www.nlm.nih.gov/mesh/D08.586.682.075.400 rdf:value
> > "D08.586.682.075.400" .
> >
> > _:a dc:subject http://www.nlm.nih.gov/mesh/D08.586.682.075.400 .
> > _:b dc:subject http://www.nlm.nih.gov/mesh/D08.586.682.075.400 .
>
> There is no problem with continuing that approach
>
>
> > So I suppose my question is really about those encoding schemes where
> > the individual values are literals rather than "multi-attribute
> > objects", and where the schemes are not closed lists of values. The date
> > encoding schemes are the example I have in mind.
> >
> > For date schemes, for example, are there any advantages/disadvantages to
> > choosing an approach based on rdfs:Class (as at present), with
> > encoding-scheme-values as separate resources i.e.
> >
> > dcterms:W3CDTF rdf:type rdfs:Class .
> >
> > _:b dc:date _:y .
> > _:y rdf:type dcterms:W3CDTF .
> > _:y rdf:value "1999-09-25T14:20+10:00" .
> >
> > over an approach based on rdfs:Datatype, with encoding-scheme-values as
> > typed literals
> >
> > dcterms:W3CDTF rdf:type rdfs:Datatype .
> >
> > _:b dc:date "1999-09-25T14:20+10:00"^^dcterms:W3CDTF .
>
> The latter should be more easily machine checkable since the typed
> literal has the lexical form - the "1999-09-25T14:20+10:00" - and
> the data typed - the dcterms:W3CDTF - in one place. The multiple
> triples version just needs more work. The datatyped literal could
> also be turned into a more efficient machine form that is likely to
> be much better/more efficient such as a programming language datetime
> format (say POSIX seconds), a database-supported date format, with
> the advantages of more efficient storage and query of such things.
> This is of course expected.
>
> > And if the second convention _is_ preferable for whatever reason, that
> > would appear to suggest we would use two different approaches to
> > representing two different types of encoding scheme.
> >
> > Pete
> >
> > [DCQ-RDF-XML] http://dublincore.org/documents/dcq-rdf-xml/
>
> Stuff still for discussion I think, in what to recommend. We're
> interested in what people will do with this stuff.
>
> Dave
>
>
|