Re: Comments on RDFa in XHTML: Syntax and processing

Mark Birbeck writes:

> If you parse the entire document, create a complete graph, and then in
> some "consuming application" make available to some _other_
> application only one triple, then I would say that your are "fully
> conforming". That is because the parser has created a full graph,
> which is then filtered before being presented to some other layer.

Hmm.  By reading it was pretty clear that the processor had to make the 
whole graph "available" to the application, and that was my concern. 

> But that's very different to your parser only recognising
> @property="foaf:name", for example, but rejecting all other
> predicates. I'm not sure in what sense that could be called "fully
> conforming", even if in some situations it might be very useful.

It depends what your goal is.  Remember, my first quibble was about trying 
to specify conformance of processors in what is basically a language 
specification.  The word "reject" is a bit loaded, but I think you want to 
encourage people to build a wide variety of software that leverages the 
information available in RDFa.  If you want to specify conformance for 
that software at all, then I would think the key concept should be that 
the output of the software should never contradict what you would have 
concluded had you correctly constructed the whole graph.  I don't think 
you'd so much "reject" all predicts, as return a result saying "you seem 
to have been looking for the triple that specifies an email address, and 
there is no such triple."  I don't see that as rejecting the others, just 
acknowledging that they are uninteresting for the purpose.

I believe that people will write and such software anyway.  The question, 
I think, is whether you want to leave the impression that it is 
incompatible with the Recommendation.  The existing text seems to suggest 
that it is.  Not a disaster, but I don't see why you're discouraging it.

As I said before, if you wanted to define a subclass of conforming 
software called a "general purpose RDFa processors" and require that it 
make the entire graph available, I think that would make a lot of sense.

Again, not a big deal.  People will write the software if they need it, 
whether the Recommendation officially blesses it or not.

> The related scenario we wanted to protect against was where a parser
> produced _too many_ triples. We felt that it was leaving RDFa open to
> being watered-down, and fragmented, if we allowed additional triples
> to be added to the default graph without the syntax driving those
> triples being part of the standard.

Yes.  I don't think anything either of us has suggested particularly opens 
the door to having random extra information included as part of the 
conforming processor interface.  If I write software that makes additional 
triples available, then I should be able to claim RDFa processor 
conformance only insofar as I can distinguish the triples that came from 
the full default graph (I.e. purely from the RDFa) from those I might have 
discovered through other means.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Mark Birbeck" <mark.birbeck@webbackplane.com>
08/29/2008 07:36 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     "Ralph R. Swick" <swick@w3.org>, 
public-rdf-in-xhtml-tf@w3.org
        Subject:        Re: Comments on RDFa in XHTML: Syntax and 
processing


Hi Noah,

Many thanks for your excellent comments. To make it easy to discuss
things, I'm going to keep this email purely on the issue of default
graphs and conformance.


Ralph replied to your original comments, like this:

>> If the observable behavior of such software is indistinguishable from
>> software that does construct the full default graph then it is
>> impossible to prove non-conformance and so we would not care.

You have replied:

> On this one I'm not convinced.  Let's say I build a piece of software 
that
> exposes exposes to applications exactly one triple from the graph. 
That's
> all the API I've built can do;  it's a special purpose API that returns 
if
> available, say, the email address for some requested principal.  The
> triple is correct, and so the output is indistinguishable from that 
which
> would be produced by software that first built the whole graph, and then
> provided the one triple.  The software is useful and it does what my
> application needs;  it's also easier to write and debug than something
> that exposes the whole graph.
>
> The problem is, your draft says my software is nonconforming.  The draft
> says that conforming software must "MUST make available to a consuming
> application a single [RDF graph] containing all possible triples".  My
> software fails that test, because it exposes only one triple.  To make 
it
> conforming, I have to add APIs to my software that will expose all the
> other triples, even though I know that my particular application will
> never call for those other triples.

I wonder if the layers are being mixed up a bit, here, though.

If you parse the entire document, create a complete graph, and then in
some "consuming application" make available to some _other_
application only one triple, then I would say that your are "fully
conforming". That is because the parser has created a full graph,
which is then filtered before being presented to some other layer.

But that's very different to your parser only recognising
@property="foaf:name", for example, but rejecting all other
predicates. I'm not sure in what sense that could be called "fully
conforming", even if in some situations it might be very useful.

The related scenario we wanted to protect against was where a parser
produced _too many_ triples. We felt that it was leaving RDFa open to
being watered-down, and fragmented, if we allowed additional triples
to be added to the default graph without the syntax driving those
triples being part of the standard.

However, parsers are free to create _additional_ graphs, and this is
what leaves the door (wide) open for experimentation.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Saturday, 30 August 2008 01:26:45 UTC