Re: Dublin Core and multiple element concern

>>>Pat Hayes said:
> Dave said:
> >5. DCMI expects xml:lang attribute to be allowed on XML
> >   <dc:title xml:lang="en">title of thing</dc:title>
> >
> >and the DCMI community wants to be able to get at that language value
> >somehow.  I strongly support this.
> >
> >I have been asked by some people in DCMI community how RDF models
> >this and could not give an answer.
> 
> Dave, this keeps coming up and I would like to tackle it, but Im not 
> sure how, or even if, this XML feature is supposed to map into RDF 
> triples. If the answer is obvious to you, could you briefly explain 
> it, using Ntriples?

Some answers I see are:

  1 N-Triples (current version)
    <thing> dc:title "title of thing" . 

    Loses the language; but there might be an application-specific
    method on the model that returned the language string.  

    However, this is old RDF M&S territory and if it isn't in the
    model, how can it be interoperable?

  2 Ntriples+ (with lang-strings):
    <thing> dc:title "title of thing"(en) .

    See Jeremy and Bill deHora's analysis:
    http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Sep/0341.html

    but it does seem awfully tricky and a bit ugly adding another
    pair where there used to be a Unicode string.


Maybe the proper expansion (to 3 triples with a bnode) is what we
will have to recommend, and deprecate the method above

   <dc:title xml:lang="en">title of thing</dc:title>

in favour of
   <dc:title xml:lang="en" rdf:value="title of thing"/>
which generates the 3 Ntriples by using an abbreviated syntax form:

    <thing> dc:title _:a .
    _:a xml:lang "en" .
    _:a rdf:value "title of thing" . 


Howver that will be a *very* hard sell to the DC community.

i.e without language
   <dc:title>title of thing</dc:title>
and with:
   <dc:title xml:lang="en" rdf:value="title of thing"/>
will be hard to explain


> >6. The DCMI has the idea of "encoding schemes" for expanding on the
> >value of the simple string valued property like above.  This is the
> >closest thing to data types here.
> >
> >In the Qualified DC in RDF/XML document above, it is recommended to
> >model like this (If I understand it correctly).
> >
> ><dc:subject>
> >   <rdf:Description>
> >     <rdf:value>19D10</rdf:value>
> >     <rdfs:label>Algebraic K-Theory of spaces</rdfs:label>
> >     <rdfs:isDefinedBy rdf:resource="URI2"/>
> >   </rdf:Description>
> ></dc:subject>
> >
> >The rdfs:isDefinedBy might point to any relevant URI2 that defines
> >the encoding - such as a term in a controlled vocabulary; this would
> >not be to an RDF(s) document.
> >
> >Optionally an rdf:type might also be used to point to a node of type
> >rdfs:Class in an rdf schema if such existed.
> >
> >The rdf:value isn't required to point to a literal; it might point to
> >another blank node with another rdf:value, rdfs:label
> 
> Hmm, thats an interesting idea. What would rdf:value mean if it wasnt 
> pointing to a literal? For example what relationship between _:x and 
> _:y would this state:
> _:x rdf:value _:y .
> _:y rdf:value "10" .


The DC idea being referred to here was historically labelled "dumbing
down".  This was for DC applications just looking for literals about
a resource (node) for some purpose, they follow the rdf:value arcs
until they get a string, and use that.  It is a flattening algorithm
for all the properties of a resource.

See 3.2 of http://dublincore.org/documents/2001/11/30/dcq-rdf-xml/

Dave

Received on Thursday, 7 February 2002 12:11:17 UTC