- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 3 Sep 2010 12:01:57 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: RDFa WG <public-rdfa-wg@w3.org>
- Message-Id: <7E900B46-EE87-4FF4-B0F1-BCF823220DCA@w3.org>
I just looked at the mailing list as linked from the issue on tracker (as an aside: this tracker is really a good tool if we use it well...) and I agree that the conclusion reflect the consensus of the time... The only new element that we have since then is that we _know_ that dialects like XHTML+RDFa will have a default profile file. Ie, the mechanism is available from a technical point of view. However, there were lots of discussion on the social issue, namely, what prefixes/terms to add to such a default profile, and those remain unsolved. Ie, the only set of prefixes that one could add to such default profile would be, in my view, the namespaces for the W3C recommendations, ie, rdf, rdfs, skos, owl, xsd. Whether it is worth the trouble for those, I do not know. Ivan On Sep 2, 2010, at 17:10 , Manu Sporny wrote: > If there are no objections to this proposal in 7 days, we will close > ISSUE-11: default prefix declarations. > > http://www.w3.org/2010/02/rdfa/track/issues/11 > > The consensus of the group seems to be that it is the job of the Host > Language to define a default RDFa Profile, and thus the default > collection of prefixes and terms: > > http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#hostlangconf > > Therefore, this is no longer an issue that is specific to the RDFa Core > document. This issue is specific to the XHTML+RDFa and HTML+RDFa > specifications and should not block RDFa Core from going into Last Call. > > It was also mentioned that the default RDFa Profile documents for both > XHTML+RDFa and HTML+RDFa should express a number of terms (aka: > LinkTypes) that were previously hard coded in the RDFa Core document. > > The exact terms to declare are dependent on resolving ISSUE-35, and only > affect the Host Language default RDFa Profile document (not RDFa Core): > > http://www.w3.org/2010/02/rdfa/track/issues/35 > > As far as prefix declarations are concerned, the group seemed to settle > on the notion that declaring prefixes like foaf and dcterms and leaving > out vocabularies like doap and vcard would generate backlash from each > respective vocabulary community and could be misconstrued as playing > favorites. > > The prefixes that are used are largely application dependent. We expect > that RDFa Profiles will be used to declare these application-dependent > prefixes. Rather, it's not the responsibility of the host language to > pick and choose application domain specific vocabularies. > > While this still doesn't address the desire for terms like > datatype="xml", and prefixes that are commonly used like "xsd" and > "rdf", declaring some prefixes and not declaring others will most likely > confuse authors and increase the cognitive load of learning and using RDFa. > > Therefore, the group is erring on the side of consistency: > > 1. There will be a default set of terms defined in the default RDFa > Profile for the host language - largely to provide backwards > compatibility with HTML4. > 2. There will be no prefixes defined in the default RDFa Profile for > XHTML+RDFa and HTML+RDFa. This includes "rdf" and "xsd". > 3. All prefix declarations will be expressed explicitly via @prefix or > @xmlns statements, or will be placed in RDFa Profile documents for > inclusion via @profile. > > This resolves ISSUE-11, please comment in 7 days from this post if you > object to this approach. If there are no objections within 7 days, > ISSUE-11 will be closed. > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny) > President/CEO - Digital Bazaar, Inc. > blog: WebID - Universal Login for the Web > http://blog.digitalbazaar.com/2010/08/07/webid/2/ > ---- 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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 3 September 2010 09:59:48 UTC