Print

Print


Oops, just noticed that

<rdf:Description rdf:about="http://testers.mkdoc.com:80/features/">
<dcq:references>
<rdf:Bag>
<rdf:li>
<rdf:Description>
<dcq:URI>
<rdf:value>/features/accessibility/</rdf:value>
</dcq:URI>
<dc:title>accessible</dc:title>
<dc:description>Information about MKDoc's accessibility
features</dc:description>
</rdf:Description>
</rdf:li>
...etc

doesn't parse as proper RDF anyway. (Or it shouldn't...)

Regardless, using rdf:Bags for this sort of data is starting to look like
overkill to me.

Dan




On Sat, 30 Jun 2001, Dan Brickley wrote:

> On Sat, 30 Jun 2001, Dan Brickley wrote:
>
> >         http://rdfweb.org/people/danbri/2001/06/dcarch-test/rdfq-tests.html
>
>
> I've now added a third example, couched against a (tweaked) snapshot of
> some more of the same data from Chris.
>
> > ...showing that we can pull together diverse metadata using RDF/DC. This
> > example isn't too exciting since the three files are similarly formated
> > and mention different resources. It would be more fun if the three files
> > were linked using dc:relation qualifiers; maybe I'll have a go at that
> > next time. Anyway, the live example seems to work in the (SiRPAC
> > based) Java tool: it finds three resultset rows that match the query
> > expression.
>
> I've just implemented this:
>
> http://rdfweb.org/people/danbri/2001/06/dcarch-test/rdfq-tests.html
>
> DCQ/RDF test 3:
>
> [[
>         SELECT ?x, ?y, ?title1, ?title2, ?abstract1, ?abstract2, ?lastmod
>         FROM
>                 http://rdfweb.org/people/danbri/2001/06/dcarch-test/relations/features_fix.rdf,
>                 http://rdfweb.org/people/danbri/2001/06/dcarch-test/relations/humans_fix.rdf
>         WHERE
>                 (dc::title ?x ?title1)
>                 (dc::title ?y ?title2)
>                 (dcq::abstract ?x ?abstract1)
>                 (dcq::abstract ?y ?abstract2)
>                 (dcq::references ?x ?y)
>                 (dcq::modified ?y ?m)
>                 (rdf::value ?m ?lastmod)
>
>         USING   dcq for http://dublincore.org/2000/03/13/dcq#
>                 rdf for http://www.w3.org/1999/02/22-rdf-syntax-ns#
>                 vcard for http://www.w3.org/2001/vcard-rdf/3.0#
>                 dc for http://purl.org/dc/elements/1.1/
> ]]
>
>
> The query runs, and finds a single result, providing URL and title for
> each pair of pages linked by dcq:references, alongside the last-modified date
> for the referenced page. This shows that the two chunks of RDF/DC data
> have been successfully merged.
>
> To do this, I had to hack about with the data a bit:
>
> http://rdfweb.org/people/danbri/2001/06/dcarch-test/relations/features_fix.rdf
>
> Excerpt from tweaked version:
>
>  <rdf:Description rdf:about="http://testers.mkdoc.com/features/">
>  <dc:title>Features</dc:title>
>  <dcq:abstract>
>   MKDoc is a web site content management system that is very feature rich.
>  </dcq:abstract>
>  <dcq:references>
>   <rdf:Description rdf:about="http://testers.mkdoc.com/features/human-readable-web-addresses/">
>   <dc:title>Human Readable Web Addresses</dc:title>
>   </rdf:Description>
> </dcq:references>
>
> and tweaked humans.rdf file:
> http://rdfweb.org/people/danbri/2001/06/dcarch-test/relations/humans_fix.rdf
>
>  <rdf:Description rdf:about="http://testers.mkdoc.com/features/human-readable-web-addresses/">
>  <dc:title>Human Readable Web Addresses</dc:title>
>  <dcq:abstract>
>     MKDoc has been designed to generate web sites that have human  readable,
>     useable, and memorable addresses.
>  </dcq:abstract>
> [...]
>  <dcq:modified>
>   <dcq:W3CDTF>
>    <rdf:value>2001-06-28T15:07:02Z</rdf:value>
>    <rdfs:label>Modified</rdfs:label>
>    </dcq:W3CDTF>
> </dcq:modified>
>
>
>
> The interesting lesson from this is that the original structure of these
> files (which to my best of my knowledge conforms to one reading of the
> current DC/RDF draft) doesn't support such easy data merging.
>
> Instead, by using two layers of indirection, the relationship between
> this pair of resources is a little obscured. The data's there and intact,
> but RDF's "out of the box" data merging capability is (I'd argue)
> neglected:
>
> The original structure was... (excuse the indenting...)
>
>         <rdf:Description rdf:about="http://testers.mkdoc.com/features/">
>         <dcq:references>
>         <rdf:Bag>
>         <rdf:li>
>         <rdf:Description>
>         <dcq:URI>
>         <rdf:value>/features/accessibility/</rdf:value>
>         </dcq:URI>
>         <dc:title>accessible</dc:title>
>         <dc:description>Information about MKDoc's accessibility
>         features</dc:description>
>         </rdf:Description>
>         </rdf:li>
>         </dcq:references>
>
>
> The contrast is between:
>
> [page1] -- dcq:references --> [page2]  (my tweaked version)
>
> and
>
> [page1] -- dcq:references --> [ bag_1 ] --- rdf:_1 --> [ ] --rdf:value-> [page2]
>
> (Chris's original data files).
>
>
> On the basis of these experiments, I'm inclined to advise that the spec be
> amended to discourage over-use of the RDF container constructs. I'm
> actually tempted to claim that we should consider avoiding them
> altogether, since the value of data-merging imho outweighs the information
> supplied by employing the Bag/Seq/Alt machinery. But I want to make some
> more test cases before making such a claim...
>
> Dan
>