W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2011

Re: ISSUE-77: Should we mark rdf:Seq as archaic (cf ISSUE-24)

From: Ivan Herman <ivan@w3.org>
Date: Fri, 14 Oct 2011 09:39:49 +0200
Message-Id: <46507F48-6EFA-420E-B571-E9862D6077F9@w3.org>
To: RDF Working Group WG <public-rdf-wg@w3.org>
(If this was discussed at the WG meeting yesterday, sorry about the lost bandwidth)

I think we should be a little bit careful here. Indeed, there is a huge deployment of rdf:Seq out there by Adobe via XMP. Essentially, any image (or illustrator file) manipulated by Photoshop or Illustrator, but also photos produced by a number of cameras, have an embedded RDF/XML encoding of the XMP metadata, that include the usage of rdf:Seq (and also rdf:Alt). We may want to contact Adobe on this and see if they would see a problem if we did that. If somebody has direct contacts with the XMP folks, that would be the best; if not, Sandro or I can try to find those via the AC Rep of Adobe. It may well be that they plan to renew XMP, in which case we could get them as part of the conversation.

As an alternative we may choose to remove Seq & friends from the core RDFS entailment regimes, possible list them as a separate block. That would be very beneficial, because it would remove a major source of 'infinite' rules from the current entailments, ie, would help in getting, eg, the ten Horst semantics (or equivalent) be in the standard. I do not think Adobe would have a problem with that. Alternatively, we may leave them without any semantic statements at all.


On Oct 13, 2011, at 18:58 , RDF Working Group Issue Tracker wrote:

> ISSUE-77: Should we mark rdf:Seq as archaic  (cf ISSUE-24)
> http://www.w3.org/2011/rdf-wg/track/issues/77
> Raised by: 
> On product: 

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

Received on Friday, 14 October 2011 07:38:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:09 UTC