Re: Syntactic subsetting (was: Re: Minutes of RDF-WG F2F, Day 2)

On 31 Oct 2012 04:29, "Richard Cyganiak" <richard@cyganiak.de> wrote:
>
> So, XMP is defined in terms of a subset of the RDF/XML syntax.
>
> Another technology that did the same was RSS 1.0 [1]; it's essentially
defined as an XML grammar that happens to produce (1999 style) RDF/XML. It
also prominently uses rdf:Seq, and Dan was one of the editors. Unlike XMP,
RSS 1.0 predates the RDF 2004 specifications that introduced the clear
separation between the RDF data model and RDF/XML syntax; so this was
perhaps simply how things were done back then.
>
> Today I think it is crystal clear that this kind of syntactic subsetting
is an anti-pattern.

Even back in 1997, we understood the difference between syntax and data
model!

The reason specs acknowledged the existence of 'mere' syntax varied. But:

1. Pure rdfs is so passive it hurts. The author of the schema has no power
to it 'the doc should have one of these, two of those, ...'; nor any way to
hint how other schemas should show up.

2. Pure RDF can serialise in XML in countless ways. At the time this meant
that pure RDF 'formats' essentially opted out of the XML tooling universe;
and RDF tools then were weak. Wobbly parsers, pre standard APIs and proof
of concept query. XML fever was at its height, sure, but it was (and
remains) rational to value being processable by XML tools eg xslt.

3. For RSS 1.0, it was important to demonstrate close affinity with is
recent non-rdf cousin versions; most adopters had no interest in or
appreciation of RDF as RDF. This is less true, but still true, today.


We knew the RDF specs were weak and unappealing, tools immature, adoption
low (beyond DC, Netscape/Mozilla), and so on. In that context, trying to be
both RDF and XML made a lot of sense.

Some things change, some stay the same. Last week I changed the
schema.orghomepage to be Polyglot HTML - both html5 and XHTML. An
awkward double life
but I wouldn't say obviously mistaken. I think even today there are times
when being a 'mere' XML format is a big benefit to a data format.

> The way to require or prohibit use of certain classes, properties or
values in a domain standard built on RDF is by doing so on the model level.
By saying that a conforming *graph* MUST or MUST NOT have a certain shape.

Now we have sparql this story is indeed stronger. But the tools remain
weaker than XML.

> I think we should consider making this clear in a conformance clause
somewhere: Specifications that require or prohibit the use of certain RDF
terms by means of syntactic subsetting of an RDF serialization do not
conform to RDF. This would reflect the reality that such specifications
will not be interoperable with off-the-shelf RDF serializers.

Feels like 'You are either with us or against us'?

I see where you are coming from, but the statement is too strong. People
can define patterns of bytes, chars and XML or JSON constructs any way they
like, and we should encourage  all efforts that have these formats
parseable as an RDF syntax. I disagree that we should say this situation
fails to be conformant to RDF. Rather, can we say that such syntax-level
rules do not themselves count as RDF vocabularies, but rather as other
something else using an RDF vocabulary? RSS 1.0, XMP are best not
understood as RDF vocabs, but as the package of some syntax rules with some
vocabs. We don't have a good name for such things.

> (There are subtle issues here though. OGP defines a syntactic subset of
RDFa, and doesn't seem to suffer from the same problem because it's not
expected to be produced by off-the-shelf serializers. Also, specifications
that use JSON-LD are likely to prescribe a specific way of expressing the
data in JSON, and thus may end up suffering from the same kind of issues as
XMP and RSS 1.0, if there's no way to automatically produce the specific
JSON form from the graph form.)

I agree; this is why your 'crystal clear' judgement is a bit too strict.

Dan

> Best,
> Richard
>
>
> [1] http://web.resource.org/rss/1.0/spec
>
>
> On 31 Oct 2012, at 01:00, Pierre-Antoine Champin wrote:
>
> > Hi Dan,
> >
> > too bad indeed you could not come.
> >
> > Regarding the rdf:Seq issue, I really don't have a strong opinion
> > anymore. However, I would like to point out that, IMHO, the whole XMP
> > argument is moot, for the following reasons (I first keep them short
> > to spare the readers -- I detail below) :
> >
> > * XMP is not interoperable with RDF as standard RDF parser may parse
> > XMP incorrectly
> > * XMP is not interoperable with RDF as standard RDF serializers may
> > generate invalid XMP
> > * XMP is using rdf:Bag and rdf:Alt which I think we agreed to mark as
archaic
> >
> > so I dont think that the rdf:Seq issue makes a big difference in
> > alienating the XMP people... :-/
> >
> > Granted, the interoperability problems are corner cases, and in 99% of
> > cases, standard RDF tools will probably interoperate very well with
> > XMP-dedicated tools. And granted, that's a nice thing that Adobe (at
> > least tried to) adopt RDF. But marking a feature as archaic is, in my
> > view, a minor issue (its *not* deprecation) compared to the issued
> > raised above.
> >
> >  pa
> >
> > PS: more detail for the interested readers
> >
> > Refering to XMP Part 1 (Data model, Serialization and Core Properties)
> >
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/cs6/XMPSpecificationPart1.pdf
> >
> >
> > 1/ XMP is not interoperable with RDF as standard RDF parser may parse
> > XMP incorrectly
> >
> > XMP defines its own data model in section 6, and 6.2 states :
> >
> >> All names in XMP shall be XML expanded names, consisting of a
namespace URI
> >> and a local name.
> >
> > Meaning that
> >
> >  <prop xmlns="xmlns:xmp="http://example.org/ns1-">foo</prop>
> >
> > is *not* equivalent to (e.g.)
> >
> >  <ns1-prop xmlns="xmlns:xmp="http://example.org/">foo</n1-prop>
> >
> > although standard RDF parsers will actually parse the same thing.
> > While this SHOULD not happen (XMP recommends to end namespace URIs
> > with "/" or "#", basically), this *could* happen in theory.
> > Note that, according to annex B.3:
> >
> >> This is not a problem for an XMP processor that avoids use of the RDF
triple representation.
> >
> > So interoperability with RDF is clearly not seeked here.
> >
> >
> > 2/ XMP is not interoperable with RDF as standard RDF serializers may
> > generate invalid XMP
> >
> > XMP defines its syntax in terms of the RDF/XML syntax, *not* in term
> > of the RDF abstract syntax (as emphasized in annex B.3, see above).
> > More precisely and disturbingly, XMP only allows a *subset* of the
> > RDF/XML syntax, explicitly prohibiting some variants (see 7.9.3). For
> > example
> >
> >  <rdf:Seq><rdf:li>foo</rdf:li><rdf:li>bar</rdf:li></rdf:Seq>
> >
> > may not be serialized in XMP as
> >
> >  <rdf:Seq><rdf:_1>foo</rdf:_1><rdf:_2>bar</rdf:_2></rdf:Seq>
> >
> > nor as
> >
> >  <rdf:Description>
> >    <rdf:type rdf:resource="
http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq">
> >    <rdf:li>foo</rdf:li><rdf:li>bar</rdf:li>
> >  </rdf:Description>
> >
> > However, I can imagine that some RDF serializer may provide one of
> > these outputs.
> >
> >
> >
> > On Tue, Oct 30, 2012 at 6:24 PM, Dan Brickley <danbri@danbri.org> wrote:
> >>
> >> Hi Folks,
> >>
> >> On 30 October 2012 10:07, Richard Cyganiak <richard@cyganiak.de> wrote:
> >>> Today's minutes, slightly cleaned up:
> >>> http://www.w3.org/2011/rdf-wg/meeting/2012-10-30
> >>
> >> Thanks. Sorry I couldn't make it to TPAC - new job, bad timing, so the
> >> minutes are much appreciated.
> >>
> >> Just reading these, I'd like to speak up in favour of keeping rdf:Seq.
> >>
> >> rdf:List is equally annoying to use, and in some ways more fragile.
> >>
> >> rdf:List won't get used any more enthusiastically, by virtue of
> >> declaring its annoying rival rdf:Seq to be no-longer-supported.
> >>
> >> If the WG is trying to alienate the XMP folks and encourage them to
> >> re-visit their decision to use RDF, this seems a logical move.
> >> Otherwise it's the latest in a long line of the RDF community being
> >> its own worst enemy.
> >>
> >> "Millions (maybe billions) of files around the world using RDF?
> >> Awesome, let's declare the markup they use to be broken! That'll teach
> >> them to follow W3C recommendations..."
> >>
> >> Dan
> >>
> >> ps. I'm in transit between employers, but will be rejoining the WG as
> >> a Google employee in the near future. If there are substantive changes
> >> to RDFS I welcome Arnaud's offer of editing help (well, I welcome it
> >> anyway, thanks Arnaud!); if it's relatively small tweaks and a bit of
> >> polish, I have the time for that. There's a rough version in Mercurial
> >> already. We only have a couple of issues against RDFS in the tracker
> >> so far; are there more decisions that need reflecting?
> >>
> >
>