Re: Named Graphs in RDFa

On Tuesday 17 February 2009, Mark Birbeck wrote:
> Hi Kjetil,
>
> My apologies for the delay this time. :)

Well, we continue with these awful ping times :-)


> I probably didn't make it clear enough where the distinctions were
> between our two approaches, for which I apologise.
>
> So let's put Fresnel to one side -- I agree it's complicated, and if
> that was to be part of a solution it would need to be greatly
> simplified.
>
> Also, put aside my jSPARQL technique -- that's just a way for one lot
> of people to create 'formatters' that other people can use (the HTML
> author wouldn't need to get involved in that, but that's by the by).
>
> So let's simply say that there is _some_ templating language or
> technique, but we don't yet know what it is...and in fact there may
> be many.
>
> Now, that leaves us with the core of our disagreement, 

Ah, OK! Thanks a lot for taking the time to make this clear, I'm sorry I 
didn't understand enough of your argument in the first iteration to be 
able to cut to the core myself.

> I do think that named graphs are an important concept and that RDFa
> has the power to get it right. But I don't think that an RDFa
> document should have the power to place triples into _any_ named
> graph, for reasons of provenance (which I've mentioned).

Right, I'm perfectly fine that with that point-of-view, especially since 
I only require fragment identifiers.

> You want to overload the use of @xml:id (which you'll notice that the
> RDFa spec was *very* careful to avoid using, for reasons I won't go
> into here), you want to add some extra elements and attributes to
> XHTML, and you want to parse @about, etc., in different ways in
> different contexts.

Well, @xml:id is not important to me, I just wanted to use a fragment 
identifier and preferably a getElementById() for the implementation.

> On the use of @xml:id for named graphs, as I said, I think we should
> discuss that separately.

OK!

> I think the biggest problem here is the use of an extra element, and
> the fact that it seems unnecessary. The use of an extra element means
> that a 'version 1' RDFa parser would parse your markup differently to
> a 'rat-enabled' parser. The latter would realise that it has a
> template, but the former would just parse @about as normal.

Indeed, this is a weakness. Also, I am much more of an RDF guy than 
X(.*)ML guy, so I do find your idea very attractive. However, I do not 
quite understand it completely, and I don't feel that it is completely 
clear how complex the solution would be, neither for the simplest case 
I outlined on  http://www.kjetil.kjernsmo.net/software/rat/ nor some 
more complex cases I have in mind. So it needs more elaboration.

> My main point, though, is that I don't think we need to do this at
> all, because if we say that the core of your proposal is the notion
> of expressing both a query and substitution template in one go, why
> not just do this:
>
>   <div typeof="rat:Template">
>     <span rel="rat:endpoint" href="http://dbpedia.org/sparql"></span>
>     <div rel="rat:pattern" datatype="rdf:XMLLiteral">
>       ...
>     </div>
>   </div>
>
> Then all your processor has to do is to run through the triples
> obtained from parsing the entire document, find any item of type
> 'rat:Template", and then begin processing the templates. (That's what
> my processor does, except it looks for Fresnel rules, but the
> principle is the main point here.)

OK, I think the idea of using RDF to describe the template metadata is 
very interesting, but I don't quite see how the full example would be.
Is this what you have in mind:

  <div typeof="rat:Template">
    <span rel="rat:endpoint" href="http://dbpedia.org/sparql"></span>
    <div rel="rat:pattern" datatype="rdf:XMLLiteral">
       <div about="sub:resource">
	<div property="rdfs:label">Resource Description Framework</div>
	<div property="rdfs:comment" datatype="rdf:XMLLiteral"><rat:variable 
name="sub:comment"/></div>
      </div>
    </div>
  </div>

If this is what you have in mind, wouldn't you need to run the parser in 
two passes? First get the triples describing the triples, then another 
run to parse the actual template.

Or did you have something else in mind?

> For example, in my opinion the 'alt' attibute on the (X)HTML 'img'
> tag could be regarded as an rdfs:label for the image:
>
>   <img alt="Me on holiday" src="holiday.png" />
[...]
> So by allowing me to add an rdfs:label to some separate graph in my
> processor, I can still achieve 100% conformance -- because my default
> graph matches the one described by the spec -- at the same time as
> allowing me to experiment and try out new things.

Great example!

> > The main argument against this approach is duplication of data, but
> > that is a minor thing compared to the potential usefulness of the
> > approach.
> >
> :)
>
> I know that people always say that, but for me, if I end up with
> duplication, alarm bells start ringing and I try to find a more
> efficient way.

Hehe!

> But anyway, that's not an argument for, or against, so let's put this
> to one side.

Yup!

> [These comments are mainly relevant to your named graph proposal, in
> the situation where the graph attribute has @about-like properties.]

OK, so I'll skip it for now.

> >> In the library I mentioned, I've taken an approach to templating
> >> that is based on Fresnel [2]. To be brutally honest, I think
> >> Fresnel is a bit over-complicated :), but I felt that since it
> >> already existed, it would probably make sense to start with that,
> >> and then add things as it became clear what else was needed.
> >
> > Yeah, we also looked at Fresnel, and we came to the opposite
> > conclusion. :-)
>
> Which conclusion? I said that it's over-complicated, which I think
> you agree with. ;)

Yeah, but you came to the conclusion that you wanted to use it anyway, 
we concluded we wouldn't use it yet. :-)

> > I see! But I feel that this is a lot further from RDFa than my
> > proposal.
>
> Mmm... with respect, I'm *only* using RDFa. :)

True! But it is further away in the sense that you'd need to understand 
a lot more stuff than RDFa to actually use it efficiently.

> The solution I am suggesting -- not the use of Fresnel, but the
> general algorithm that you create some 'well-known predicates' which
> your parser then finds after loading -- would create exactly the same
> triples in both your parser, and a parser that is unaware of your
> templating rules.
>
> However, the solution that you've outlined in your document would
> actually produce different triples in your parser. For example:
>
>   <rat:graph xml:id="query2" endpoint="http://dbpedia.org/sparql">
>     <tr about="sub:resource">
>       <td property="foaf:name"
> datatype="rdf:XMLLiteral"><rat:variable name="sub:name"/></td>
>       <td property="dbo:produced">1973</td>
>       <td property="dbp:firstFlight"
> datatype="rdf:XMLLiteral"><rat:variable name="sub:first"/></td>
>     </tr>
>   </rat:graph>
>
> In this example, in your templating language, @about is not a
> subject, but a subject that will be substituted. This means that in
> your parser there would be no triple generated by this, but in
> another parser there would.

Yeah, that's the nastiest part of my proposal, I feel... I was thinking 
a while that I should do something like <tr about="{sub:resource}"> to 
mark that this isn't a real subject, but that would conflict with my 
other goal of having as few modifications to the RDFa parser as 
possible... 

But then, the same weakness is present with the solution above, even 
though it appears to the first pass as a mere XML literal. But I 
suppose this is far from what you actually had in mind, so I'll refrain 
from raising more straw-men, and hope you will take the time to explain 
in more detail. :-)

> Here I'm afraid I cannot be so laissez-faire; using
> @xml:id and named graphs is something that has to be designed right
> for all of RDFa, not just one use case. 

Sure! I'd just like to do some exploratory coding to see if what I have 
in mind is useful. 

> With such a lengthy email -- sorry about that!

Not at all! Thanks for taking the time to share these concerns!

> The key thing is that I'm all for having a templating language, but
> would urge that it is done using 'normal' RDFa, rather than adding
> new features.

I understand! So far, I tend towards a solution where a templating 
language is not RDFa, but conceptually close enough so that authors can 
get up to speed and write useful things with little effort. However, I 
think your points are very interesting, so I hope you still have some 
time to discuss this topic.

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer
kjetil@kjernsmo.net
Homepage: http://www.kjetil.kjernsmo.net/     OpenPGP KeyID: 6A6A0BBC

Received on Sunday, 8 March 2009 20:59:40 UTC