W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2012

Re: ISSUE-129 (Power of @vocab): Change the power of @vocab, related to default term interpretation [3rd LC Comments - RDFa 1.1 Core]

From: Niklas Lindström <lindstream@gmail.com>
Date: Tue, 14 Feb 2012 00:22:20 +0100
Message-ID: <CADjV5jezmZuCPrWO3hdv0xL8e+Wqyk5CJjCq-0fjVK0VjoRvpQ@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: public-rdfa-wg@w3.org
Hi Shane, Ivan,

In <http://creativecommons.org/ns#>, cc:license is defined to be
owl:sameAs xhv:license, and rdfs:subClassOf dc:license. It also has
rdfs:domain cc:Work and rdfs:range cc:License. So the use of it
implies an rdf:type for the subject and object as well.

RDFa 1.0 explicitly defined @rel="license" to mean xhv:license.
Creative Commons are silent on the exact IRI of the predicate when
used without the 'cc:' prefix though -- they only use the wording "In
this case, the relationship is "license" -- but as we know they do use
RDFa.

In general, I'd recommend dc:license, since it is the most general of
the three. But I would still prefer to allow authors to control this
with @vocab.


To reply to your comments Shane, I'm not sure I understand what you
mean by this changing randomly? Authors have full control over the
vocabulary for terms with @vocab (and as we've seen, they have to
exercise this to manage the situation in <head> and with e.g.
'prefetch' or 'nofollow').

Of course, someone may add
@vocab="http://www.example.org/randomURI/somepage#" to the body, just
as they might add @prefix="foaf:
http://www.example.org/stochasticURI/otherpage#". I mean, this is what
RDFa is about. If you don't control the surroundings of your markup,
you either have to rely on a contract with the manager of that, or
explicitly use @prefix, @vocab and/or full IRIs to control your
properties and types.

I am sympathetic to your appreciation of 'license', but I wonder if it
really is so generally ingrained in authors that it warrants such a
special treatment? With my proposal it would still always mean
xhv:license (or e.g. cc:license if we change it) unless someone
explicitly uses @vocab (which even so can be reset again with an empty
value). This is all very dependent on the expectations and background
knowledge of authors, as well as how vocabulary publishers want @vocab
to work with their vocabularies. Imagine e.g. if Schema.org mint their
own IRI for 'license' in the future. (Not that *I* would like that,
but such is the playing field which I want us to level.)

It is the uniformity of expression in markup like this that I think we
should value:

    <div vocab="http://purl.org/dc/terms/">
      <h2 property="title">The Origin of Species</h2>
      <p>License: <a property="license"
          href="http://creativecommons.org/licenses/publicdomain/">
          Public Domain</a>.<p>
    </div>

Here's another example. I wonder what most people would expect from:

    <dl vocab="http://www.w3.org/2006/vcard/ns#" typeof="VCard">
      <dt>Name</dt><dd property="fn">Corky Crystal</dd>
      <dt>Role</dt><dd property="role">Officer</dd>
      <dt>Email</dt><dd property="email">corky@example.com</dd>
    </dl>

I really doubt that it's obvious that 'role' in the above actually
means xhv:role!

For 'role' specifically, I am unable to find where its use as a term
in the @rel attribute is specified. I find old drafts of it used as
such in <link> elements in XHTML2, but I thought this was superseded
by the specific @role attribute used by WAI-ARIA? May it even be that
we don't need to define 'role' as a reserved term?

Perhaps many authors (and systems) really do expect 'describedby',
'license' and 'role' to be fixed to their predefined IRIs even when a
local vocabulary is active. I only believe that it's just as probable
that many will not, but will instead expect that @vocab works
uniformly without special exceptions.

One idea could be to cater for *both* of these expectations. If the
rules instead were cumulative -- i.e. even if a term mapping is found,
@vocab would have effect -- then this:

    <a vocab="http://purl.org/dc/terms/" property="license"
href="/cc-by">CC-BY</a>

would produce *two* statements:

    <> dc:license </cc-by> .
    <> xhv:license </cc-by> .

At least this way, no information is lost. But it would be really
gnarly in e.g. the case of the vCard role example above, where the two
conflicting properties don't even nearly resemble each other. :/

.. Granted, if 'role' *could* be safely removed (leaving only
'license' and 'describedby'), and if 'license' was changed to mean the
very general 'dc:license', I suppose I would be pacified enough even
without any rule changes. At least if no one else sees this as an
issue, and assuming nothing like <http://schema.org/license> would
ever come up as contentious.

Best regards,
Niklas



On Mon, Feb 13, 2012 at 10:35 PM, Shane McCarron <shane@aptest.com> wrote:
> I have not found the reference but that doesn't mean it isn't true.  Steven,
> can you please confirm that the XHTML WG intent was that 'license' meant
> 'cc:license' in XHTML2?  That's where RDFa comes from.
>
>
> On 2/13/2012 1:06 PM, Ivan Herman wrote:
>>
>> On 13 Feb 2012, at 19:22, Shane McCarron<shane@aptest.com>  wrote:
>>
>>> I don't really mind.  license in xhv should point to cc license anyway,
>>> which in turn might point somewhere else.  XHTML says that its license is
>>> the same as cc:license (I think)
>>
>> Shane, could you check this? If this is indeed the case, then we should
>> definitely define that to be cc license and, I believe, that would alleviate
>> Niklas' issue, too.
>>
>> Thanks
>>
>> Ivan
>>
>>
>>> and that is surely what we meant.  Entailment should make this work
>>> right...
>>>
>>> On 2/13/2012 12:21 PM, Ivan Herman wrote:
>>>>
>>>> Shane,
>>>>
>>>> and what about my idea that might also pacify Niklas, namely that
>>>> 'license' would not be mapped against the xhv:license property as now but
>>>> rather to dcterms:license? The fact of the matter is that, at least in the
>>>> RDF world, *nobody* uses xhv:license for, well, license, everybody uses
>>>> either dcterms or cc...
>>>>
>>>> Cheers
>>>>
>>>> Ivan
>>>>
>>>> On Feb 13, 2012, at 17:46 , Shane McCarron wrote:
>>>>
>>>>> Yes.  I read your mail.  I respectfully disagree.  Just because we can
>>>>> do a thing does not necessarily mean we must do a thing.  As an anecdote, I
>>>>> am going to cite something that happened back in the day when I was part of
>>>>> X3J16 (ANSI C++ standards committee).
>>>>>
>>>>> Everyone wanted C++ to be maximally flexible.  Lots of people had GREAT
>>>>> ideas about how to accomplish this.  One such idea was that it should be
>>>>> possible to redefine every operator to do anything.  So, for example, an
>>>>> object could make it so '+' meant '-'.  Or worse yet, so '+' meant '*'.  At
>>>>> the time this was hailed as a brilliant piece of abstraction.  In reality it
>>>>> was idiotic. Some things need to be constant.
>>>>>
>>>>> We have defined a VERY limited set of things that are constant and can
>>>>> be relied upon to work everywhere all the time.  As an author, I appreciate
>>>>> this.  'license' means license.  It does not mean
>>>>> http://www.example.org/randomURI/somepage#license.  I know this and I am
>>>>> thankful.  I know this in the same way I know that 'foaf:' is defined as a
>>>>> prefix for me, and that it means the right thing.  I wouldn't want that to
>>>>> change randomly either.
>>>>>
>>>>> On 2/13/2012 10:21 AM, Niklas Lindström wrote:
>>>>>>
>>>>>> Hi Shane,
>>>>>>
>>>>>> On Mon, Feb 13, 2012 at 4:42 PM, Shane McCarron<shane@aptest.com>
>>>>>>  wrote:
>>>>>>>
>>>>>>> My immediate reaction to this is "ummm... no?"  We can't reverse this
>>>>>>> order.
>>>>>>>  It would mean that if there is EVER an @vocab then terms don't work.
>>>>>>>  Why
>>>>>>> would we want terms to not work?  Or am I missing something?
>>>>>>
>>>>>> Yes, I explain why in depth in my email (specifically the section
>>>>>> "Predefined terms") [1], and Ivan had some thoughts on it as well [2],
>>>>>> which I'll reply to as soon as I can.
>>>>>>
>>>>>> The short answer as to why is: because terms can clash with the intent
>>>>>> of authors relying on @vocab to apply uniformly.
>>>>>>
>>>>>> Kind regards,
>>>>>> Niklas
>>>>>>
>>>>>> [1]:
>>>>>> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0021.html
>>>>>> [2]:
>>>>>> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0024.html
>>>>>>
>>>>>>
>>>>>>> On 2/13/2012 2:24 AM, RDF Web Applications Working Group Issue
>>>>>>> Tracker
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> ISSUE-129 (Power of @vocab): Change the power of @vocab, related to
>>>>>>>> default term interpretation [3rd LC Comments - RDFa 1.1 Core]
>>>>>>>>
>>>>>>>> http://www.w3.org/2010/02/rdfa/track/issues/129
>>>>>>>>
>>>>>>>> Raised by: Niklas Lindström
>>>>>>>> On product: 3rd LC Comments - RDFa 1.1 Core
>>>>>>>>
>>>>>>>> The essence of the proposal change the rules in 7.4.3 to:
>>>>>>>>
>>>>>>>> [[[
>>>>>>>> * If there is a local default vocabulary, the IRI is obtained by
>>>>>>>> concatenating that value and the term.
>>>>>>>> * Otherwise, check if the term matches an item in the list of local
>>>>>>>> term mappings. First compare against the list case-sensitively, and
>>>>>>>> if
>>>>>>>> there is no match then compare case-insensitively. If there is a
>>>>>>>> match, use the associated IRI.
>>>>>>>> * Otherwise, the term has no associated IRI and must be ignored.
>>>>>>>> ]]]
>>>>>>>>
>>>>>>>> See related mails
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Shane McCarron
>>>>>>> Managing Director, Applied Testing and Technology, Inc.
>>>>>>> +1 763 786 8160 x120
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Shane McCarron
>>>>> Managing Director, Applied Testing and Technology, Inc.
>>>>> +1 763 786 8160 x120
>>>>>
>>>>>
>>>> ----
>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>> Home: http://www.w3.org/People/Ivan/
>>>> mobile: +31-641044153
>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Shane McCarron
>>> Managing Director, Applied Testing and Technology, Inc.
>>> +1 763 786 8160 x120
>>>
>
> --
> Shane McCarron
> Managing Director, Applied Testing and Technology, Inc.
> +1 763 786 8160 x120
>
>
Received on Monday, 13 February 2012 23:23:18 UTC

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