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

Re: rev and the costs of inverses/aliases in SPARQL

From: Ivan Herman <ivan@w3.org>
Date: Mon, 08 Mar 2010 19:24:13 +0100
Message-ID: <4B9540CD.30806@w3.org>
To: Richard Cyganiak <richard@cyganiak.de>
CC: Dan Connolly <connolly@w3.org>, public-sparql-dev <public-sparql-dev@w3.org>, public-rdfa <public-rdfa@w3.org>
Richard,

I think I agree with everything you say: indeed, I do not expect @rev to
be very widely used. For most of the cases @rel is working. But there
are cases when @rev _is_ very handy and useful.

There is a difference between an attribute that is not widely used but
occasionally very useful and removing that attribute altogether. I think
that DanC's question was about the latter...

Ivan

On 2010-3-8 18:10 , Richard Cyganiak wrote:
> My €0.02: I find @rev handy sometimes because it allows me to be clever
> and reduce markup. But if @rev didn't exist, then I could cope by
> changing the structure of the markup to something a bit more verbose
> (but probably easier to understand -- it's easy to be too clever, as
> Bijan observed).
> 
> I think that there will be strong pressures on vocabularies to be
> RDFa-friendly, and that most vocabularies of the future will be designed
> so that typical markup scenarios can be solved without @rev.
> 
> I see @rev as a band-aid. Using vocabularies that haven't been optimised
> for RDFa is less painful if you have @rev. With optimised vocabularies,
> it will be rarely or never used.
> 
> (What do I mean by “optimised”? I don't mean vocabularies with lots of
> inverses. I mean vocabularies where each property has the direction that
> occurs naturally in page markup. I think that almost all relationships
> have such a “natural” direction if used in web pages. Admittedly that's
> conjecture.)
> 
> Best,
> Richard
> 
> 
> On 8 Mar 2010, at 16:41, Ivan Herman wrote:
> 
>>
>>
>> On 2010-3-8 16:00 , Dan Connolly wrote:
>>> I just ran into this message again from an HTML 5 validator:
>>>
>>> "The rev attribute on the a element is obsolete. Use the rel attribute
>>> instead, with a term having the opposite meaning."
>>>
>>> This seems to encourage the pattern of minting an inverse
>>> for each property, a la:
>>>
>>>  abridgement
>>>  abridgementOf
>>> -- http://vocab.org/frbr/core.html
>>>
>>
>> From an RDFa point of view, if I am an author, I consider using a
>> specific vocabulary and I use the attributes as they are defined.
>> Authors cannot be expected to mint additional predicates on the fly if
>> those are not defined; this is way too much for many of them anyway.
>>
>>> Doesn't that just gum up the works when doing SPARQL queries? Which
>>> do you query for, abridgement or abridgementOf? Or do you use
>>> a UNION?
>>>
>>> It's one thing to discover, post-hoc, that two properties are
>>> inverses of each other, and to write down that relationship.
>>> But to make up these inverse-aliases by choice seems like
>>> a big waste, to me.
>>> (see also http://esw.w3.org/topic/HasPropertyOf bit on inverses and
>>> aliases)
>>>
>>> How are SPARQL users dealing with this in practice?
>>>
>>>
>>> Meanwhile, RDF/XML doesn't have syntax for inverting a relationship
>>> (a la is/of in N3), and there's data that says rev="..." is
>>> too confusing for HTML authors to use.
>>>
>>
>> I am not sure RDF/XML is relevant. RDF/XML gives you different ways of
>> expressing triples, so one can encode anything freely, there is no real
>> constraint. In the case of RDFa there is an additional constraint that
>> one wants to follow the HTML structure to include the presentation
>> content.
>>
>> It is of course possible, in RDFa to express everything with @rel only
>> but, in some cases, the missing @rev makes it very convoluted.
>>
>>> "The short answer is unfortunately "NO". Use of "rev" SHOULD be
>>> avoided."
>>> -- http://microformats.org/wiki/rel-faq
>>> "the only <link rev=""> link to appear is rev="made" (to point to the
>>> author's page) — and the latter is not used that much more than the more
>>> sensible rel="author". Also, ironically, just off the graph in position
>>> 21 is rel="made", probably showing that the distinction between rel and
>>> rev may be too subtle for many authors."
>>> -- http://code.google.com/webstats/2005-12/linkrels.html
>>>
>>>
>>> Would the RDFa authoring community miss a/@rev if it went away?
>>> Does anyone have 1st-hand experience to share?
>>>
>>
>> I think Damian has just posted a good use case example.
>>
>> Another example is
>>
>> <img rev="foaf:depiction"
>>     resource="http://www.ivan-herman.net/foaf#me"
>>     src="http://www.ivan-herman.net/Images/me2003-small.png"/>
>>
>> That gives me
>>
>> <http://www.ivan-herman.net/foaf#me>
>>   foaf:depiction <http://www.ivan-herman.net/Images/me2003-small.png> .
>>
>> Without a @rev, I have to add a new hierarchy to do the same:
>>
>> <div about="http://www.ivan-herman.net/foaf#me" rel="foaf:depiction">
>>   <img src="http://www.ivan-herman.net/Images/me2003-small.png"/>
>> </div>
>>
>> Which unnecessarily complicates the structure.
>>
>> There is another issue. There is already deployed RDFa out there. Quite
>> a lot, actually. As a consequence, there is a strong requirement of
>> backward compatibility in the RDFa WG charter. This also means that if
>> the @rev is removed from the core HTML5 document, RDFa will have it
>> alongside the RDFa specific attributes like @about or @resource...
>>
>> Ivan
>>
>>
>>
>> -- 
>>
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF   : http://www.ivan-herman.net/foaf.rdf
>> vCard  : http://www.ivan-herman.net/HermanIvan.vcf
>>
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf



Received on Monday, 8 March 2010 18:23:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 March 2010 18:23:52 GMT