Describing documents and their parts

Hi all!

I obviously got the current behaviour of @instanceof backwards (I'm
afraid I've been out of the loop for about a month). It is clear to me
now that it will *not* type a chained @resource, only the present
@about or generated bnode. I don't dispute this (and am terribly sorry
for speaking up before reading up on the more than month-old
discussions).


The cause of my concern is a use case in my current work, which I'd
like to describe here for your advice. (Btw., this is the project
mentioned in <http://rdfa.info/2007/10/02/rdfa-in-use-in-government/>.)

We are using RDFa to describe legal documents (the real publications,
not the xhtml information resources, which are representations *about*
those) with properties and references, and *their parts* (chapters,
articles) -- to be able to talk about, reference and analyze those in
detail.

I need to establish a relation between such a document and its parts
(@id:d fragments). I will only talk about "top level parts" here, but
parts within parts would follow this same logic as well (articles
within chapters, advice sections within articles etc).

These are the triples I want (I use a simplified made-up vocabulary
here since ours is tightly bound to swedish legal concepts):

    </publication> ex:section <#section-1> .
    <#section-1> a ex:Section .
    </publication> ex:appendix <#appendix-a> .
    <#appendix-a> a ex:Appendix .

Consider this skeleton example, with typed subjects in place but none
of the needed composition relations:

    <body about="/publication">
        <div id="section-1" about="#section-1" instanceof="ex:Section">
        </div>
        <div id="appendix-a" about="#appendix-a" instanceof="ex:Appendix">
        </div>
    </body>

Until I realized that @instanceof now only applies to the subject
resource, I had been using this markup:

    <body about="/publication">
        <div id="section-1" rel="ex:section" resource="#section-1"
             instanceof="ex:Section">
        </div>
        <div id="appendix-a" rel="ex:appendix" resource="#appendix-a"
             instanceof="ex:Appendix">
        </div>
    </body>

Since this no longer works, I can mainly think of three solutions,
given here with some criticism of each:


------------------------------------------
1. Duplicated container relations
------------------------------------------

    <body about="/publication">
        <div id="section-1" about="#section-1" instanceof="ex:Section">
            <span rev="ex:section" resource="/publication"/>
        </div>
        <div id="appendix-a" about="#appendix-a" instanceof="ex:Appendix">
            <span rev="ex:appendix" resource="/publication"/>
        </div>
    </body>

[+] short type declaration
[+] quite clear semantics, id and about seem "correlated", the div is
"about" its content
[-] has to repeat the container resource when giving the relation to the part.


------------------------------------------
2. Verbose type (and possibly odd semantics)
------------------------------------------

    <body about="/publication">
        <div id="section-1" rel="ex:section" resource="#section-1">
            <span rel="rdf:type" resource="ex:Section"/>
        </div>
        <div id="appendix-a" rel="ex:appendix" resource="#appendix-a">
            <span rel="rdf:type" resource="ex:Appendix"/>
        </div>
    </body>

[+] saves repetition of container resource
[-] verbose type declaration (sacrificed type shorthand in favour of
non-repeated container resource)
[-] perhaps odd, since the identified div "carries the relation to itself".


------------------------------------------
3. Hanging rels, with artificial div:s
------------------------------------------

    <body about="/publication">
        <div rel="ex:section">
            <div id="section-1" about="#section-1" instanceof="ex:Section">
            </div>
        </div>
        <div rel="ex:appendix">
            <div id="appendix-a" about="#appendix-a" instanceof="ex:Appendix">
            </div>
        </div>
    </body>

[+] saves repetition of container resource
[-] artificial wrapping div ("div-itis"), may not work at all in some
cases due to doctype or "conventional" restrictions, editing tools and
similar.


IMHO, neither of these are ideal. Perhaps hanging rels (#3) is "best",
but it can cause problems due to the power of hanging (which is
currently debated), and not the least due to the mentioned "divitis"
which can become really messy. I would have preferred to describe
parts of a document and their relations in a very compact way, since
RDFa does it so well for descriptions of many other things. Granted,
it's still readily possible of course, and there is obviously more
than one way to achieve my need.

I can imagine the next step for me could be something like hGRDDL
instead (although it doesn't exist even in working draft form yet), to
achieve the terseness and DRYness I desire.


.. One crazy thought I had was to "kidnap" e.g. @role
(<http://www.w3.org/TR/xhtml-role/>) for this, to establish both the
relation between parent container and part, and while I'm at it
perhaps also the repetition of the fragment id in @about (since @role
is reasonably about the element itself (that fragment of the
document), at least by default -- the "overloading" with @about
*could* affect the semantics I suppose). It'd look like:

    <body about="/publication">
        <div id="section-1" role="ex:section" instanceof="ex:Section">
        </div>
        <div id="appendix-a" role="ex:section" instanceof="ex:Appendix">
        </div>
    </body>

Admittedly, I *really* force the semantics of @role here to mean: "the
role of an element is the relation from its container to it" and maybe
I should just use a @class and hGRDDL). Apart from that, this solution
would fit this specific case perfectly. :)


But I wonder, aren't use-cases like this likely to be a common use for
RDFa? I've always thought so (at least cases like <h1
property="dc:title"> very much suggests it). Am I missing something?
Or am I just trying to get too much of the RDFa goodness at the
expense of its generality?

What do you think?

Best regards,
Niklas

Received on Wednesday, 9 January 2008 17:21:09 UTC