W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > November 2011

Re: Agenda for telco, 2011-11-17

From: Niklas Lindström <lindstream@gmail.com>
Date: Thu, 17 Nov 2011 15:44:24 +0100
Message-ID: <CADjV5jfP+piU6T-YM7Wx=MXp0ogPECD2oTa+A40TUsr0xD_hzQ@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: W3C RDFWA WG <public-rdfa-wg@w3.org>, Manu Sporny <msporny@digitalbazaar.com>
On Wed, Nov 16, 2011 at 4:23 PM, Ivan Herman <ivan@w3.org> wrote:
> Manu is at a conference, so we agreed I would propose an agenda for our telco tomorrow, that I will also chair.
>
> We have what I believe are relatively low hanging fruits, ie, issues where we seem to have agreement on (based on the email discussion) and it would be good to have them out of the way. Actually, we may want to speed up things by making an informal vote on these before the meeting... We can then look at some of the more 'hairy' issues if we have time.

Here are my reflections (sorry for the ranting analyses, but I need
more information before voting):

> 2. Low hanging fruits on the issue list:
>  - ISSUE-97: Determine if datetime should be supported in HTML5
>  http://www.w3.org/2010/02/rdfa/track/issues/97

Yes. As Ivan also says, we have to stick to the rules HTML5 defines
for lexical values. I assume (at least hope) that it is still possible
for us to map those rules to XSD datatypes in a clear way. (So that
the literals will get the appropriate xsd datatypes.)

.. The issue is, I think, that we need to continuously track HTML5 (a
"living standard"...), so I suppose we leave this out of RDFa core and
make RDFa in HTML(5) also "living" until this stabilizes. Due to the
fact that we (AFAIK) desire to make certain *elements* (here <time>)
determine datatyping, *or* specific attributes on such (or all)
elements, we may have to define that this (host-specific
interpretation of certain element/attribute combinations) is possible
in core as well?

(I'd like to note that I'm not entirely opposed to lexical matching,
but I agree that it borders on harmful magic. I'd very much prefer
special, dedicated elements or attributes with limited lexical
variation. The <time> element can give us this, providing xsd:date,
xsd:dateTime or xsd:time compliant (detectable) values with either
@datetime, @value or whatever the final attribute will be. My goal is
just to, is possible, have some unambiguous short form to supply date
and dateTime values without the need for explicit @datatype
annotations. I'd probably even welcome a veritable attribute fest of
@date, @datetime, @time and so on in HTML5 if that was to happen. ;) )


>  - ISSUE-113: Add the value attribute of the HTML data element as a possible literal target for property
>  http://www.w3.org/2010/02/rdfa/track/issues/113

Yes. I have the same stance as for ISSUE-97 above. I'm for it in
principle, provided that <data> + @value will be kept. I'm a bit wary
of the merit of that element itself; but that is for the HTML5 WG to
decide on.


>  - ISSUE-116: Consider owl terms for vocab expansion
>  http://www.w3.org/2010/02/rdfa/track/issues/116

Yes. (Will the support for rdfs:subClassOf and rdfs:subPropertyOf
still remain? I hope so, although I *think* the mentioned OWL terms do
convey more of the intent we look for. I'd like to have seen
owl:sameAs support as well, but I trust Ivan on the risk of that
complicating things.)


>  - ISSUE-118: Should we consider allowing the '/' character in a term
>  http://www.w3.org/2010/02/rdfa/track/issues/118

Yes. (And only that. (As you may know, I would like to se '/'
*disallowed* as the first char of the local part of a CURIE as well,
but I believe that ship has sailed.))


> 3. ISSUE-108: Refine/deprecate Link relations for the RDFa 1.1 Default Profile
> http://www.w3.org/2010/02/rdfa/track/issues/108

This is hard. Given the recent changes to @property, perhaps
restricting predefined link terms to only work in @rel (and @rev), and
only keeping a limited subset of unambiguous known terms (primarily
"license") is more viable than deprecating them all. I'm specifically
concerned about rel="license" as used by Creative Commons.

AFAIK, we have these sub-issues (please correct me if some of these
are resolved):

* Should @vocab "reset" the slate, or should these predefineds "shine
through"? (My vote: Ideally, but what about e.g. 'stylesheet'?)
* Should 'bookmark' magically use the parent element @id as subject?
(My vote: No.)
* Should 'license' always apply to the document base regardless of
current subject? (My vote: No.)
* Should 'copyright' alias to 'license' at parse time? (My vote: No.
This can be done with owl:sameAs in the vocabulary.)
* Should 'alternate' and 'stylesheet' be combined? (My vote: No.)

Such complexities are what the simple and explicit use of RDFa should
replace, so I would like to sweep them all aside somehow. Granted, it
is technically possible to define this really special treatment if it
were deemed important to preserve long-standing semantics. I just
doubt that most of those special rules are expected to be semantically
effective in existing markup (e.g. "alternate stylesheet" is only
interpreted as syntax keys by the rendering engine, nothing actually
reasons over them semantically).

So perhaps we need an explicit "drop list" for most, and a "keep list"
for e.g. 'license'? These should probably "shine though" @vocab (with
the rule that ':license' binds to current vocab). And as said, I
believe this should *only* apply to @rel/@rev.

.. Finally, I am against supporting a microformats wiki of growing
terms. Unless in theory the default @vocab would be set to a link
leading to a live OWL representation of that page, under the
provenance of the W3C... But I have a hard time believing in
wide-spread, serious endorsement of fickle relations such as
'sweetheart'...


(I'm of course also very interested in discussing ISSUE-119:
http://www.w3.org/2010/02/rdfa/track/issues/119, but I fear our agenda
is more than full already.)

Best regards,
Niklas
Received on Thursday, 17 November 2011 14:45:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:18 GMT