W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

PROPOSAL #2 to close ISSUE-39: rdfa term mapping triples

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 18 Oct 2010 21:08:51 -0400
Message-ID: <4CBCEFA3.9020406@digitalbazaar.com>
To: RDFa WG <public-rdfa-wg@w3.org>
If there are no objections to this proposal by this Thursday, October
21st at 13:00 UTC, we will close ISSUE-39: rdfa term mapping triples.

http://www.w3.org/2010/02/rdfa/track/issues/39

There was a previous proposal to close this issue:

http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0002.html

Richard Cyganiak objected to closing the issue and there was a healthy
amount of discussion (which you can read above, not going to re-hash it
here). Mark is also going to respond and provide his more detailed
reasoning later.

In the end, the Working Group could not reach consensus on the new
mechanism proposed by Ivan, which Richard pointed to in his response:

http://www.w3.org/2010/02/rdfa/wiki/ProfileSpec

Richard also asked that we provide a rejection based on the RDF
Semantics document. The section on "Interpretations" is a good starting
point for understanding Richard's request:

http://www.w3.org/TR/rdf-mt/#interp

While it is true that one could model RDFa Profile documents in a
variety of different ways, and that there is no "proper RDF way" of
doing so, telecon discussion highlighted that this is not what was meant
by "the proper way to model prefixes and terms".

The way that we've always approached CURIEs in RDFa is as a mapping of
one string to another string. That is, generally speaking, a CURIE is
the expansion of one string into another string. It is NOT the expansion
of one string into an IRI. While you could argue this for terms, we
chose to keep the two conceptual models the same in order to make it
easier to explain (if something as pedantic as this ever comes up).

The lexical space of a CURIE is larger than the lexical space of IRIs,
in fact, IRIs don't enter the equation until after a CURIE (or a Term)
is resolved and interpreted... and only then is an IRI discussed - as
the value space of a CURIE.

In other words, CURIEs and Terms are more about strings, less about
IRIs. Now, while this may seem strange to some, it is consistent. It is
a mental model that has been consistent throughout the development of
RDFa 1.1. It is the way that the RDFa WG has decided to conceptually
model CURIEs and we feel that keeping that conceptual model consistent
is important. The consistency argument is what seemed to resonate with
most people.

The impact that this conceptual model has is that the RDFa Profile
documents are a bit more difficult to model than we'd like, but it
doesn't seem to have caused major negative feedback from those that have
created RDFa Profile documents. In other words, those that have decided
to create RDFa Profile documents have gotten it right in every case. If
an RDFa Profile document is wrong, the RDF output will be wrong (and
easily detected). We expect that RDFa Profile document authors are going
to be more expert than most and that what little implementation burden
there is will not prevent people from creating RDFa Profile documents.

Even if one were to disagree with this conceptual model, there is no
alternative proposal that has gathered as much consensus as the current
approach.

This proposal asserts that since the Working Group has evaluated every
alternative proposal offered to the group, and that the approach in the
current RDFa Core 1.1 spec is the one that garnered the most support,
that the issue is resolved and should be closed.

Please comment before Thursday, October 21st at 13:00 UTC if you object
to this proposal. If there are no objections by that time, this issue
will be closed. If there are objections, the RDFa Working Group will
perform a straw-poll and decide whether or not to close the issue before
entering Last Call.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Saving Journalism - The PaySwarm Developer API
http://digitalbazaar.com/2010/09/12/payswarm-api/
Received on Tuesday, 19 October 2010 01:09:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC