Re: Official Response to ISSUE-121 from RDF Web Apps WG

Hi Sebastian,

Based on your feedback, we kept the issue open and discussed it again
during the last teleconference call to make absolutely certain that the
Working Group didn't want to pursue the @id/@typeof combination. The
full discussion can be found here:

http://www.w3.org/2010/02/rdfa/meetings/2012-03-01#ISSUE__2d_121__3a____40_id_to_set_subject

Responses to your replies are below.

On 01/29/2012 09:49 PM, Sebastian Heath wrote:
> The discussion in the teleconference[1] isn't very complete but
> suggests there is reason to keep this issue alive.

It is unfortunate that the teleconference minutes gave that impression.
For the avoidance of doubt, the group was quite sure that it did not
want to pursue the @id/@typeof mechanism. The group was also certain
that they did not want to pursue the more general concept of using @id
to set the subject, for RDFa Core 1.1.

> GK wrote "it's always been something I would've liked, my primary use
> case for RDFa is for legal information, where we refer to document
> fragments more often than not."
>
> NL wrote " (.. the 0.05 is for my dream of a good working solution
> ;)".
>
> The above suggests the idea is worth pursuing.

Both of those comments were from Niklas and were not intended to show
support for using @id to set the subject. During the discussion, Niklas
also said:

Niklas Lindström: Too complicated, don't support it.

He also further clarified his position in the last telecon as:

Niklas Lindström: for the record, I do not want @id to be used as @about
or @resource because of HTTP Range-14. My thought was that in certain
scenarios, there could be a number of cases where @id could be similar
to @about, but when looking to an implementation, it was clear it was a
real problem.

So, I hope this makes it clear that not a single person in the Working
Group would like to re-open and pursue the idea that @id would set the
subject in RDFa Core 1.1. Further reasoning as to why is given below:

>> 1. There are a slew of non-trivial HTTP-Range-14 issues about which
>> namespace @id refers to and which namespace @about refers to that
>> would be raised. Document identifiers mixing with semantic item
>> identifiers would be problematic at best.
>
> HTTP-Range-14 issues come up in some contexts, but by no means all
> and so their simple invocation is inconclusive.

The particular issue of most concern to the Working Group is the idea
that a fragment identifier specified using @id coupled with @typeof
could generate a subject that exists in semantic-space vs.
document-space. That is, what @id can generate would change from what it
has traditionally been (a document fragment identifier), to something
new (a document fragment identifier /or/ a semantic identifier). It's
value space would shift based on other attributes on the same element -
which would be thoroughly confusing to authors.

A few have argued that identifiers specified using @id, and identifiers
specified using @about, belong in the same space. This concept has been
rejected a number of times, most notably by the Technical Architecture
Group at the W3C and this Working Group.

Both groups have asserted that an IRI constructed using @id can only
specify a fragment identifier in a document. An IRI constructed using
@about can refer to a semantic identifier /or/ it can refer to a
fragment of a document. The problem raised by shifting the semantic
meaning of the @id attribute (in languages like HTML) can be summarized
in this example:

<p id="sebastian" typeof="foaf:Person">...</p>

If the Working Group were to adopt what you are proposing, the following
triple would be created:

<#sebastian> rdf:type foaf:Person .

However, #sebastian is also a document fragment identifier. A processor
that is extracting the semantics of only the document itself could
extract a triple like so:

<#sebastian> rdf:type html:FragmentIdentifier .

So, now, the reasoning system would conclude that not only are you a
person, but you are a part of a document as well. This ambiguity
introduced by collapsing the spaces of @id and @about is why we have
traditionally tried to keep the two spaces of @id and @about separated.

That is, @id refers to IRIs in document-space, while @about refers to
IRIs in semantic-space (which may also refer to IRIs in document-space).
Introducing your feature would reverse that decision and provide authors
with a way to easily conflate the two spaces... which they will
certainly do.

>> 2. It would break existing documents that use @typeof and @id on
>> the same document.
>
> A simple versioning mechanism for RDFa in XHTML would solve this.

Yes, but then an author would have to look at the top of the document to
understand if @id and @typeof would generate a triple together or not.
In general, we don't want to have to make document authors think that
much about this feature. It is true that we made a few
backwards-incompatible changes in RDFa 1.1, but in each case, all the
pros and cons were weighed against each other. Requiring authors to
refer to the document version adds further complexity for the author. It
also introduces the HTTP-Range-14 issue above. The benefit, in the
opinion of the Working Group, does not outweigh the negative consequences.

>> 3. It would make RDFa more complicated than it already is.
>
> How? For the use cases I suggest[2], it would make things simpler.

While it may make it simpler for the use case you propose, it would make
understanding RDFa more complicated. Especially since there is already a
mechanism in RDFa Lite 1.1 to accomplish what you are proposing:

<p resource="#sebastian" typeof="foaf:Person">...</p>

>> 4. There are no compelling use cases - that is, most use cases can
>>  already be addressed using the attributes that exist right now.
>
> I offered 2 in a further comment [2] but it seems they weren't
> addressed. Or I should say I offered two cases that were compelling
> to me. GK added what might be considered another.

The Working Group considered your use cases and Niklas' use cases (they
weren't GK's use cases). We did not find that the benefits outweighed
the drawbacks.

Based on the reasoning above, the Working Group made a final decision on
the matter:

The Working Group reaffirms that @id MUST NOT be used to set the subject
in the RDFa Core specification.

http://www.w3.org/2010/02/rdfa/meetings/2012-03-01#resolution_2

While the Working Group considers this issue closed at this point, if
you would like to re-open the issue, we ask that you provide new
evidence that we had not considered before.

Thank you, Sebastian, for your feedback on RDFa 1.1, and for your
suggestion on making RDFa better for authors. While the Working
Group may not agree with the approach, we certainly appreciate your
effort and thought on the matter.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Monday, 5 March 2012 03:23:32 UTC