Kia ora,

Thanx again for feedback on my attempt at RDF/XML encoding of DCQ data.  I think I am beginning to get my head a little further around the complexities of RDF (though I do sometimes find myself wondering if it's worth it - see point 3 below)...

*** 1. Use of rdf:value nodes (also IMT use in medium) ***

>>> [log in to unmask] 27/07/02 02:43:36 >>>
> > <dcq:medium>
> >   <dcq:IMT>image/jpeg</dcq:IMT>
> > </dcq:medium>
> Your problem here is that the dcq:IMT element gets interpreted as an RDF
> typedNode. This is a mistake I made lots while learning RDF. Remember
> explicit RDF has a "striped" syntax, the XML elements alternate between the
> nodes and arcs of the graph.

Alan also went on to suggest:

>  <dcq:medium>
>    <rdf:Description>
>      <dcq:IMT>image/jpeg</dcq:IMT >
>    </rdf:Description>
>  </dcq:medium>

Mikael also pulled me up on IMT usage and suggested an alternative correction:

>>> [log in to unmask] 26/07/02 20:49:57 >>>
> This is simply invalid RDF. <dcq:IMT> is not a property that can have a
> value, it's a Class (that can have properties). Thus, rdf:value is not
> "mandatory" in this case, it's only *necessary* ...

>>> [log in to unmask] 27/07/02 03:08:47 >>>
> Douglas, please note that (as recently discussed on this list) dcq:IMT
> cannot be used with dcq:medium, only dc:format. So correct usage is
> actually:
>  <dc:format>
>    <dcq:IMT>
>      <rdf:value>image/jpeg</rdf:value>
>    </dcq:IMT>
>  </dc:format>

I see now my version was not recognising the node-arc "striped" structure of RDF.  Both the above suggestions appear to generate the intermediate node I was missing, though with slightly different graphs.  

I'm guessing the second version (using rdf:value) is preferred for DC as this is how the examples in the DCQ RDF proposal appear??

*** 2. Nested local elements ***

>>> [log in to unmask] 26/07/02 20:49:57 >>>
> > We have multiple links to various size/format digital objects.  Putting
> > just the URI inside Relation refinements doesn't give enough information
> > to be able to distinguish between them.  We decided to use EAD [13]
> > elements (or possibly METS [14] elements in the future).  However, the
> > W3C validator didn't like the multiple nested XML elements (multiple
> > ead:daoloc inside an ead:daogrp), eg:
> >   <ead:daogrp>
> >     <ead:daoloc ead:role="thumbnail" ead:behavior="image/jpeg" ead:href="ephanznationalparty19490105_00000089_tn.jpg" />
> >     <ead:daoloc ead:role="display" ead:behavior="image/jpeg" ead:href="EphANZNationalParty19490105_00000089_pv.jpg" />
> >     <ead:daoloc ead:role="reference" ead:behavior="image/jpeg" ead:href="ephanznationalparty19490105_00000089_df.jpg" ead:title="Digital image of This top-heavy government; what you have to pay for. [1949]. (83 KB)" />
> >     <ead:daoloc ead:role="source" ead:behavior="image/tiff" ead:href="ephanznationalparty19490105_00000089_ds.tif" ead:title="Digital source image of This top-heavy government; what you have to pay for. [1949]. (83 KB)" />
> >   </ead:daogrp>
> 
> Again, this is invalid RDF. I suppose ead:role, ead:behavior, and
> ead:href are Properties. Then ead:daoloc is a Class, and ead:daogrp must
> be a Property. A property can only point to *one* value. If you want to
> group values together (which is not necessarily useful in your case),
> consider putting them in an rdf:Bag/Seq/Alt, like so:
>    <ead:daogrp>
>     <rdf:Bag>
>      <rdf:li>
>        <ead:daoloc ead:role="thumbnail" ead:behavior="image/jpeg" ead:href="ephanznationalparty19490105_00000089_tn.jpg" />
>      </rdf:li>
>      <rdf:li>
>        <ead:daoloc ead:role="display" ead:behavior="image/jpeg" ead:href="EphANZNationalParty19490105_00000089_pv.jpg" />
>      </rdf:li>
>      <rdf:li>
>        <ead:daoloc ead:role="reference" ead:behavior="image/jpeg" ead:href="ephanznationalparty19490105_00000089_df.jpg" ead:title="Digital image of This top-heavy government; what you have to pay for. [1949]. (83 KB)" />
>      </rdf:li>
>      <rdf:li>
>        <ead:daoloc ead:role="source" ead:behavior="image/tiff" ead:href="ephanznationalparty19490105_00000089_ds.tif" ead:title="Digital source image of This top-heavy government; what you have to pay for. [1949]. (83 KB)" />
>      </rdf:li>
>     </rdf:Bag>
>    </ead:daogrp>
> Could be overkill, though :-)

I see I have four options here:

a. My current fix - remove the ead:daogrp layer and lay the ead:daoloc's flat [a fix which has already presented a limitation, as fixes  always do...]

b. As Mikael suggests above using rdf:Bag and rdf:li elements.

c. Same as c, but condense slightly (replace the ead:daoloc element with the rdf:li directly), which appears to result in the same graph anyway:

<ead:daogrp>
  <rdf:Bag>
    <rdf:li ead:href="http://digital.natlib.govt.nz/20020604/ephdmoran1920s_00000653_tn.jpg" ead:role="thumbnail" ead:behavior="image/jpeg"/>
    <rdf:li ead:href="http://digital.natlib.govt.nz/20020604/ephdmoran1920s_00000653_pv.jpg" ead:role="display" ead:behavior="image/jpeg"/>
    <rdf:li ead:href="http://digital.natlib.govt.nz/20020604/ephdmoran1920s_00000653_df.jpg" ead:role="reference" ead:title="Digital image of Buy lemons and make fresh lemonade.  [1920s]. (51 KB)" ead:behavior="image/jpeg"/>
    <rdf:li ead:href="http://digital.natlib.govt.nz/source/20020605/ephdmoran1920s_00000653_ds.tif" ead:role="source" ead:title="Digital source image of Buy lemons and make fresh lemonade.  [1920s]. (51 KB)" ead:behavior="image/tiff"/>
  </rdf:Bag>
</ead:daogrp>

d. Picking up on Mikael's property/class comments, redefine the relationships so each role becomes a separate RDF class.  (The disadvantage is if we add more classes our RDF schema needs to be changed.)  I guess a sample may look like this:

<ead:daogrp>
  <rdf:Description>
    <nlnzdl:thumbnail ead:behavior="image/jpeg" ead:href="ephanznationalparty19490105_00000089_tn.jpg" />
    <nlnzdl:display ead:behavior="image/jpeg" ead:href="EphANZNationalParty19490105_00000089_pv.jpg" />
    <nlnzdl:reference ead:behavior="image/jpeg" ead:href="ephanznationalparty19490105_00000089_df.jpg" ead:title="Digital image of This top-heavy government; what you have to pay for. [1949]. (83 KB)" />
    <nlnzdl:source ead:behavior="image/tiff" ead:href="ephanznationalparty19490105_00000089_ds.tif" ead:title="Digital source image of This top-heavy government; what you have to pay for. [1949]. (83 KB)" />
  </rdf:Description>
</ead:daogrp>

I think option c. looks the best/cleanest.  Which leads me on to point 3...

*** 3. RDF-isation of DC in XML ***

As an XMLer and not an RDFer, I've found trying to create XML that will behave like RDF quite a challenge.  RDF offers some useful constructs like containers and rdf:resource, except when you're expecting consistency in your XML, they just appear to complicate matters (eg. present all encoding schemes like this, except URLs which should be like this... etc...).

I think RDF is a powerful thing, but it will only create powerful results if it gets used.  I think I've said before more XMLers might pick it up if there was a less daunting "RDF-Lite" (just as SGML took off when SGML-Lite (XML) appeared).  Perhaps some of the RDF style questions I have raised may not have come up?  Perhaps there could be a profile similar to how the W3CDTF note limits the larger ISO 8601??  Would this be more appropriate at the W3C level or the DCMI level??  Would this be appropriate at all??  

I know trying to satisfy both XMLers and RDFers may be asking more than is possible, but (assuming RDF does hope to get wider take-up) I think RDF may need to adapt to meet potential user needs if it wants to survive.  I have heard several people making DC implementation decisions say things like "DCMI is pushing RDF but it's long-term survival is really unclear, whereas XML schemas are being widely used right now so let's just use XML schemas...".

Food for thought...

Thanx,
Douglas Campbell
National Library of New Zealand