Re: Reification support in RDFa

Elias,

A few more notes to add to your summary, for the benefit of people who
might be wondering why we'd even risk toying with such a beast as
reification. :)

The argument *for* reification is usually that organisations such as
IPTC have already said that they need it. They have documents that can
move through the publishing process and at each step of the way, more
metadata can be added; they need to be able to indicate not only who
added the data, but other 'meta-metadata' such as how confident was
the person that added the metadata about what they added, when it was
added, and so on.

For example, to indicate that an article is about skiing, they might do this:

  <link rel="iptc:category" href="[iptc:skiing]" />

But to indicate that some automatic process suspects that the article
is about skiing, and is 80% sure of that, based on the words in the
article, they might do this:

  <link rel="iptc:category" href="[iptc:skiiing]">
    <meta property="iptc:confidence" content=".8" />
  </link>

Now, I say that this is "usually" the argument for reification (put
forward by me whenever anyone says "we don't need reification" :)),
but recently another one has come up, that is just as
important--perhaps more so. The use case is using RDFa features to
provide internationalisation.

We have said in the XHTML 2 draft that the following two pieces of
mark-up are equivalent from an RDF standpoint:

  <blockquote title="Main quote">
    ...
  </blockquote>

  <blockquote>
    <meta property="title">Main quote</meta>
    ...
  </blockquote>

In other words, a property on an element can be expressed via a meta
or link element as a child. The advantage of this is that the contents
of @title can now be internationalised. When this is applied to the
link element, it provides a way to create internationalised labels for
browsers like Opera to make use of:

  <link rel="next" href="abc.html">
    <meta property="title">Next document</meta>
  </link>

But the problem here is that without reification, it's difficult to
see what this mark-up might mean in RDF terms; the predicate xh:title
is obviously not a property of either of the documents being linked
from or to, so we are left with two choices:

 * it is the title of the link itself--or the statement in an RDF sense--and
   therefore we need reification, because we are making statements
   'about' this statement;

 * it is a property of the relationsip defined around the predicate "next",
   in which case we need n-ary relationships.

Given the need for 'statements about statements' more generally, I
think the @title should be a title for the statement, and therefore it
seems we need reification. However, even without this broader need, I
think the n-ary relationship technique doesn't work for us here, and
so reification would still be required. To achieve the n-ary approach,
we would need to create an anonymous node that itself has a
relationship to the document:

  <> xh:link _:a .
  _:a xh:next <abc.html> .
  _:a xh:title "Next document" .

However, we've now lost the 'direct' relationship between this
document and the 'next' document, as expressed by:

  <> xh:next <abc.html> .

I guess this could be added back in by inference...so this approach is
not so bad. And it does provide an interesting regularity if the
approach is taken to all elements:

  <blockquote>
    <meta property="title">Main quote</meta>
    ...
  </blockquote>

  <> xh:blockquote _:b .
  _:b xh:title "Main quote" .

Funnily enough, it ties in somewhat with a very old approach I had way
back when; when I first started doing all this metadata work for the
HTML WG the mental picture I had was actually this:

  _:a rdf:type xh:link .
  _:a xh:rel xh:next .
  _:a xh:href <abc.html> .
  _:a xh:title "Next document" .
  _:b rdf:type xh:blockquote .
  _:b xh:title "Main quote" .

In other words, each element is an anonymous node of the same rdf:type
as its element name. It does mean though that all relationships
between 'this document' and other documents now have to be inferred
from this mass of triples that represents the document.

(If we went that route, I'd have to reverse my arguments on @role and
@class! I'll save that for another email, since it would also open up
another way to do striping.........)

Anyway, to summarise; these are some of the use-cases, and the
discussion on the telecon was that, given that reification is still an
awkward area within RDF perhaps we should steer clear of it. Although
I think that reification is sufficiently clearly defined for us to use
it here, even if there are grey areas elsewhere--which is I think,
what DanC is getting at--it also seems that there are other options
open to us, namely the creation of an 'automatic' anonymous node.

I think my vote is still for reification, but I'd certainly be
interested to hear comments of the anonymous node solution, and others
if people have them.

Regards,

Mark


On 17/10/06, Elias Torres <elias@torrez.us> wrote:
>
>
>
> Dan Connolly wrote:
> > On Mon, 2006-10-16 at 17:32 -0400, Elias Torres wrote:
> >> During today's meeting we were discussing our current support for RDF
> >> reification in our current syntax draft [1] which states:
> >>
> >> [[[During subject resolution (which could be triggered by object
> >> resolution for a rev attribute), the processor may traverse up the DOM
> >> tree in search of an about  attribute. If a link or meta element is
> >> encountered before an about attribute is found, and if this link or meta
> >> element itself does not have an about attribute, then the subject (or,
> >> again in the case of rev, object) is resolved as the [RDF/A statement]
> >> represented by this link or meta  element.]]]
> >
> > I'm not fond of specifying meaning of documents in terms
> > of behavior of software ("the processor may...") but the example
> > that followed makes it pretty clear what's going on; and what's
> > going on falls completely within RDF as specified in the 2004
> > Recommendations. The turtle output is completely ordinary RDF:
> >
> >  <> cc:license <http://creativecommons.org/licenses/by-nc-nd/2.5/> .
> >  <> dc:creator "Mark Birbeck."
> >  _:a rdf:type rdf:Statement .
> >  _:a rdf:subject <> .
> >  _:a rdf:predicate cc:license .
> >  _:a rdf:object <http://creativecommons.org/licenses/by-nc-nd/2.5/> .
> >  _:a dc:creator "Ben Adida" .
> >
> >
> >> The main discussion point was who are the folks (such as IPTC and others
> >> from HTML WG) asking for reification and what the real requirement is
> >> for RDFa. Additionally, I brought up the point that the reification [2]
> >> vocabulary is not either clearly defined, implemented or used today and
> >> that we must be careful on taking on such a task.
> >
> > I think it's reasonably well defined. It does not meet quoting
> > requirements, but the example in this RDFa draft doesn't involve
> > real quoting.
>
> That's correct. The example in the syntax document is the classic RDF
> reification definition: Ben said a statement with the following s,p,o.
>
> >
> >
> >>  Reification in RDF M&S
> >> leans towards identification of statements as opposed to quotation [3].
> >> It's not clear which one we want in RDFa.
> >
> > I don't see anything that suggests you want quotation. What
> > am I missing?
>
> Maybe you are not missing anything and I just did a poor job of
> summarizing the issue for the mailing list (which was my action during
> the meeting) and instead clouded the issue. But at least we had another
> pair of eyes to look at it.
>
> Besides the id/quote issues in reification, I believe is still to be
> resolved what do we name the statements themselves. M&S says that the
> identifier should identify a specific triple instance in an RDF document
> and we don't necessarily have an RDF document, Named Graph, etc. Do you
> think that this is an issue?
>
> Another small issue is that an element could generate N number of
> statements (rel, rev, property, + multi-value rel/rev attribute values)
> and we haven't discussed whether a reification property applies to all
> of those statements. When I say we don't know the exact requirement is
> whether we are looking to give provenance on the HTML element or on a
> specific RDF triple generated from the HTML (i.e. Ben added the @rel
> value, but Mark added @rev). Can we distinguish between those two? Do we
> need to? It seems to me that if we are going to define how to add
> provenance to HTML documents/fragments we must address this question.
>
>
> >
> >> I'd like for us (everyone) to discuss more how do we really want to
> >> approach reification in RDFa, especially since we have a better
> >> situation due to us dealing with HTML documents. We have documents being
> >> published on the web at specific locations and I think we have different
> >> two major ways to frame the issue/requirement. We might want to track
> >> provenance at the HTML/element level (e.g. who wrote what piece of HTML)
> >> vs at the RDF level (who said which triple). I think one option is for
> >> us to establish our purpose and provide a specific vocabulary to do so
> >> without dragging the whole use/mention, bnodes, named graphs issues
> >> attached with RDF reification and the communities trying to resolve it.
> >>
> >> Any thoughts?
> >
> > The relevant requirement for me is that RDFa be convertible to RDF/XML;
> > i.e. no more expressive. Real quoting would involve going beyond
> > the existing expressive capability of RDF/XML.
>
> k. requirement noted and we need to make sure we don't step out of the
> realm of what's doable in RDF/XML (e.g. generate invalid XML names).
>
> >
> > But I don't see anybody arguing for that.
> >
> >> -Elias
> >>
> >> [1]
> >> http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-syntax#id0x01cc64a0
> >> [2] http://www.w3.org/TR/rdf-primer/#reification
> >> [3] http://ioctl.org/rdf/usementionmyarse
>
>
>


-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Tuesday, 17 October 2006 12:31:57 UTC