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

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.

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.

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.

(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.)

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?
>> 
>

Received on Wednesday, 31 October 2012 11:30:19 UTC