RE: comments on syntax wd: bug in graph seriali[zs]ation algo

Hi

OK, we're getting closer :)

I like that we have a MT-based story about what's going on here, too.

One puzzle:

Some graphs we're supposed to throw a 'this can't be serialized' error,
others we transform into an MT-instance and serialize. It isn't clear why
we make this distinction.

There's a trick for serializing graphs with edges whose URIref names don't
map to XML element names: one generates a new property name, delcare it a
subproperty, and run the serializer so it serializes with the new property
name instead. I would (in all my implementations) much rather do this than
throw an 'unserializable' error. And I would rather throw an
unserializable error than generate URIs to label bNodes. This might be my
personal taste. The two techniques seem similar: slight (MT-friendly)
changes to the data structure to allow it to be serialized according to
RDF/XML 1.0 syntax. My instinct is: they're either both OK, or both bad.

Gotta go do RDFS for a bit. Probably won't here more from me on this
before WWW2002...

cheers,

Dan

On Tue, 30 Apr 2002, Jeremy Carroll wrote:

> > > DanBri:
> > > > I propose section 6 be dropped for now, until this is fixed.
> Jeremy:
> > > Opposed.
> DanBri:
> > Ah, we disagree.
>
> Less than we might think.
>
> I agreed with all the facts you laid out; only disagreeing with the action.
>
> A different action could be:
> - add some test cases to clarify the difficulty
> - indicate that often we have to serialize an "instance of" a graph rather
> than the graph itself. (see model theory section 0 for defn of "instance
> of")
> - add sufficient warning text
> - change status to non-normative
>
> Test cases:
>
> error001.nt
> _:foo <eg:test> _:foo .
>
> has no corresponding RDF/XML (we already have one of these error001.nt
> somewhere).
>
> B:
>
> <eg:sk1> <eg:test> <eg:sk1> .
>
> C:
>
> <eg:sk2> <eg:test> <eg:sk2> .
>
> Then two entailment tests and four non-entailment tests (between the three
> graphs above) clarify the relationships between these graphs. By referring
> to these test cases in the serialization text the limitations of the method
> can be made clear.
>
> > > I think a minor change highlighting that the meaning of the graph has
> > > changed in such a serialization may improve the document.
> >
> > If the meaning changes, it's not a serialization so much as a
> > transformation...
> >
> >
>
> It's a fairly small transformation, and that smallness can be made clear
> model theoretically.
>
> Jeremy
>

Received on Tuesday, 30 April 2002 06:18:33 UTC