Comments on RDFa Core 1.1 Working Draft

Hi all,

This message records my comments on RDFa Core 1.1 WD dated 15 Dec 2011 [1].  This review completes my action from the RDF WG [2].

I was pleased to see the RDFa Core WD refer to IRIs in place of URIs.  This will ease transition of the RDF documents to using IRIs and not require a revisiting of the RDFa Core document.  However, there are still several places in the document that refer to URIs (even when not in direct relation to CURIEs); those should be revisited for consistency.

Most of the RDFa Core WD discusses syntactical issues.  As such, I (and hopefully the RDF WG) are agnostic.  I agree with Ivan that we should think of RDFa 1.1 as "just" another standard RDF serialization syntax.

However, we don't want to encounter any syntax or usage patterns within RDFa that results in a conflation of IRIs for both resource names and resource contents, as with SPARQL's named graphs.  This is especially important to the RDF WG, given our resolutions related to this problem in SPARQL:

  - At the RDF WG's first FTF [3], we resolved, "Named Graphs in SPARQL associate IRIs and graphs *but* they do not necessarily "name" graphs in the strict model-theoretic sense. A SPARQL Dataset does not establish graphs as referents of IRIs (relevant to ISSUE-30)".  ISSUE-30 is at [4].

The RDFa Core WD refers to RDF Concepts in relation to graph definition (sec. 3.7) [5].  This is very helpful and will allow us to update RDF Concepts as required.  However, there is possibly a confusion between a graph's name (a g-snap) and its contents at a point in time (a g-text) in RDFa Core, depending on the interpretation of the base IRI.

The RDFa Core WD, section 7.2 [6] specifies the base IRI of a document this way: "The base. This will usually be the IRI of the document being processed, but it could be some other IRI, set by some other mechanism, such as the (X)HTML base element. The important thing is that it establishes an IRI against which relative paths can be resolved."

That means, to me at least, that the base IRI is often going to be the *same as* the document IRI, thus resulting in conflation of denotation of the graph and the document.

I don't think that needs to change in the RDFa Core document, but it does mean that our named graphs discussion should take note.  The following RDF WG issues relate (and possibly more):

  - ISSUE-14 "What is a named graph and what should we call it?" [7]
  - ISSUE-15 "What is the relationship between the IRI and the triples in a dataset/quad-syntax/etc" [8]
  - ISSUE-17 "How are RDF datasets to be merged?" [9]
  - ISSUE-29 "Do we support SPARQL's notion of "default graph"?" [10]
  - especially ISSUE-32 "Can we identify both g-boxes and g-snaps?" [11]
  - ISSUE-38 "What new vocabulary should be added to RDF to talk about graphs?" [12]

Andy Seaborne has pointed out [13] that, "the doc URI is not the graph name in every case -- it is in the web cache pattern."  (By "doc URI" he meant "the RDFa document's base IRI")  That is a good point and should be considered.

Dan Brickley asked [13], "what about # URIs in RDFa: can they identify any resource?"  The RDFa Core WD has a note on this [14] which basically says "unfortunately not".

Regards,
Dave

[1]  http://www.w3.org/TR/2011/WD-rdfa-core-20111215/
[2]  http://www.w3.org/2011/rdf-wg/track/actions/128
[3]  http://www.w3.org/2011/rdf-wg/meeting/2011-04-14
[4]  http://www.w3.org/2011/rdf-wg/track/issues/30
[5]  http://www.w3.org/TR/2011/WD-rdfa-core-20111215/#graphs
[6]  http://www.w3.org/TR/2011/WD-rdfa-core-20111215/#evaluation-context
[7]  http://www.w3.org/2011/rdf-wg/track/issues/14
[8]  http://www.w3.org/2011/rdf-wg/track/issues/15
[9]  http://www.w3.org/2011/rdf-wg/track/issues/17
[10]  http://www.w3.org/2011/rdf-wg/track/issues/29
[11]  http://www.w3.org/2011/rdf-wg/track/issues/32
[12]  http://www.w3.org/2011/rdf-wg/track/issues/38
[13]  http://www.w3.org/2011/rdf-wg/meeting/2012-01-04#RDFa_LC
[14]  http://www.w3.org/TR/2011/WD-rdfa-core-20111215/#s_Syntax_overview

Received on Wednesday, 11 January 2012 13:49:39 UTC