Re: Dublin Core and multiple element concern

>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?

Many thanks.


>
>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" .

??

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 7 February 2002 11:48:28 UTC