Re: Deprecate http://www.w3.org/1999/02/22-rdf-syntax-ns# in favour of /ns/rdf# ??

Hi Dan,

That's indeed a possible scenario but I see no need for merging RDF and
RDFS, and trigger big changes.

"Say W3C announces that rdfs and rdfs will "be considered equivalent to"
> the URI http://w3c.example.org/rdfcore#"
>
In fact, we can take a much more conservative approach:
* "http://www.w3.org/1999/02/22-rdf-syntax-ns#" deprecated in favour of "
http://www.w3.org/ns/rdf#"
* "http://www.w3.org/2000/01/rdf-schema#" deprecated in favour of "
http://www.w3.org/ns/rdfs#"

With redirections and links. This would align RDF and RDFS with other
vocabularies such as PROV (http://www.w3.org/ns/prov#) and let the W3C
provide a clean and consistent offer in terms of vocabularies: all of them
are under http://www.w3.org/ns with specific sub-namespace for every
vocabulary.


"heated debate during several ESWC 2014 linked data events on whether the
> new namespace should have used # or /"
>
Well, I see that point being debated since I started working on SemWeb
technologies and it does not seem it will ever really go away...
Furthermore, both RDF and RDFS use of # could already be debated and won't
be affected by the switch to a new namespace

"The WG charter MUST address the rdf:/rdfs: version handling issue"
>
So far, there is no much version handling done on vocabularies. Whatever
namespace is used just serves the most up to date version, precisely
because people don't want to rewrite their triples. I don't see why/how
changing the namespace would suddenly make version handling a MUST in all
the documents. (Not saying version handling is not relevant but I don't
think that's the point here)

Cheers,
Christophe



On 2 December 2013 12:01, Dan Brickley <danbri@danbri.org> wrote:

>
>
>
> On 2 December 2013 10:05, Christophe Guéret <
> christophe.gueret@dans.knaw.nl> wrote:
>
>> Hi everyone,
>>
>> No surprise at the level of opposition to deprecating the namespaces
>>> (again, I point out in my defence that I raised it after someone asked
>>> me about it; as a stickler for persistence I'm happy with that outcome).
>>>
>> As we recently talked about it, it could be that Phil refers to me there
>> so feel free to blame me for the long mail thread ;-)
>>
>> I fully agree with many of the points that forked out of the main
>> proposal, namely:
>> * Make it easier to find out if something is in rdf: or rdfs: (and
>> eventually why)
>> * Provide different serialisations
>> * Provide better multilingual support
>> This would make everyone's life easier. Now.
>>
>> For the future I would still much advocate deprecating the old namespace
>> and start using the new one. If I could give only one motivation, it would
>> be that new vocabularies will be using the new namespace whereas the key
>> ones will still be using an old (and somewhat confusing) location. From the
>> outside this is not very consistent: several W3C vocabularies under
>> different locations with no clear common design pattern, usage of dates in
>> URI whereas most BP guides (rightly) say it is not a good idea, version of
>> the vocabularies different than what the URI suggest, ...
>>
>> Furthermore, deprecating does not mean having to rewrite all the triples
>> that are out there, and all the hard-coded namespaces used in every
>> software. We can just set up redirects between the terms present in the old
>> namespace to the one in the new one with a note suggesting not to use the
>> old syntax any more. This may involve a bit more HTTP tips&tricks than just
>> serving an OWL file but I don't see any big technological difficulty there.
>> We can also keep this redirection until nobody uses the old namespaces any
>> more...
>>
>> This will eventually happen as most of the RDF data out there is
>> automatically generated from some legacy formats. As the maintainers of
>> these datasets update their D2R/CSV2RDF/... scripts for using the new
>> namespaces the usage of the deprecated ones will progressively fade away.
>> Software also gets updated every now and then and new releases can safely
>> come with new parsing capabilities. There is only data and software that do
>> no see any update that will not switch to using the new namespaces... but
>> do we really want to build a Web of Data on outdated data and abandonware ?
>>
>> Anyway, for the sake of clarity and end-user friendliness, I think we
>> should keep this deprecation idea in the air while starting to work on
>> content negotiation and multi-linguality
>>
>
> I fear this would be a recipe for mild disaster. Let's sketch a timeline.
> Say W3C announces that rdfs and rdfs will "be considered equivalent to" the
> URI http://w3c.example.org/rdfcore# in December 2013.
>
> <FICTION>
>
> Maybe January 2014 someone writes a patch for librdf's raptor, such that
> it adds a mode to API and commandline of the Redland RDF parser suite such
> that they can emit triples with the new URI instead of the original URIs,
> or extra triples so we get both, "for maximum compatibility".
>
> February 2014 someone forks https://github.com/semsol/arc2 with a similar
> option, and also patches the SPARQL query engine to have option of silently
> turning queries that use rdf: or rdfs: prefixes to be querying the new URIs
> instead or as well. Dave Beckett says he'll wait to see if consensus
> settles down before deciding what to do with the raptor patch.
>
> March 2014, blog + twitter thread about whether it should also rewrite
> INSERT statements https://github.com/semsol/arc2/wiki/SPARQL- spills over
> into the Jena and Sesame mailing lists. No consensus there on exactly what
> changes ought to be proposed. Andy circulates url to his post in this
> thread.
>
> April 2014, proposals on this list advocating for update to the recently
> finalized RDFa 1.1 standard arguing that compliant RDFa parsers should
> preferentially emit triples using the new namespace not the old confusing
> ones, unless running in an explicit back-compatibility mode. W3C team
> response is that RDFa and RDF WGs have already successfully completed their
> chartered work, but that advocates for improvements should talk to their
> Advisory Committee representative about proposing a new Working Group to
> bring RDFa up to date here (or consider joining the Consortium if not
> already a member). A rough draft charter is for this is debated on the HTML
> WG lists, where it is suggested that the Microdata/RDF mapping document
> should also be updated as an essential part of this work, but that the RDFa
> Next Gen WG charter could also address the widespread desire for
> convergence between Microdata and RDFa.
>
> May 2014, heated debate during several ESWC 2014 linked data events on
> whether the new namespace should have used # or /, and whether
> http://w3c.example.org/rdfcore/ should redirect with a 303 or 302 to
> /rdfcore#
>
> June 2014, W3C advisory committee panel session on convergence plans. W3C
> management state that it is important to address the needs of the RDF and
> data linking communities but that coordination with key HTML standards is
> critical, and that any new WG would need to carefully balance
> backwards-compatibility considerations. An Adobe panel speaker notes that
> several trillion bazillion JPEGs, PDFs etc contain embedded "classic"
> RDF/XML and that it would be counter-productive for W3C to take any steps
> that suggest these hard-to-update files are in any way invalid, e.g. by
> encouraging old rdf: and rdfs: URIs to be treated as deprecated in query
> languages and APIs. Another panelist suggests a Community Group to work on
> a unit test suite for SPARQL implementations that would capture this
> requirement. Lively discussion of relevance of SPARQL entailment regimes,
> OWL and RIF is deferred due to 'lunch or beers' as the panel session is
> overrunning its scheduled AC Meeting slot.
>
> July 2014, Linked Europe Data 2030 EU project announced. Deliverables
> include patches to Jena and Sesame to bring them up to date with new modern
> RDF data linking standards such as  http://w3c.example.org/rdfcore#  Long
> email threads sprawling across several mailing lists ensure.
>
> August 2014, Email threads go quite for the northern hemispheric summer. A
> draft "minimal" SPARQL 2.0 charter is circulated for discussion, addressing
> "bugfixes and errata, RDF/S namespace versioning update and possible
> convergence paths with XQuery. Also possibly a spec for extension functions
> in a secure Javascript subset, if other work completes early. Chartered
> deliverables include "RDF/S Namespace Versioning mechanism - Use Cases and
> Requirements.". The WG charter MUST address the rdf:/rdfs: version handling
> issue, and MAY address OWL and 3rd party namespace aliasing at the
> discretion of the chair and staff contacts". The charter generates
> suprisingly little discussion - perhaps due to the time of year.
>
> September 2014, W3C announces "Beyond Maintenance Mode: rethinking RDF
> usability for 2030 and beyond" Workshop to be held in December 2014, hosted
> by Linked Europe Data 2030 project, workshop chairs include representatives
> from Adobe, Jena, Sesame projects.
>
> October 2014, RDFLib github repo merges a patch for partial
> http://w3c.example.org/rdfcore#  support in its Turtle, RDF/XML and N3
> parsers: debate in IRC, Twitter, github and email on whether bulk data
> imports from the 3rd party Trig parser, or direct via API, should also be
> canonicalized to use the new namespace, or whether this is even really
> needed. Someone back-ports the initial RDFLib patch to work with earlier
> versions, asks on mailing list how to make it available via easy_install.
>
> November 2014, semantic-web@w3.org list thread in which we're reminded
> that everything in /TR/ ought also to be updated so as to bring the
> usability of W3C's RDF-related documentation into a more modern state.
> Discussion flows as to whether a hypothetical Community Group to
> 'coordinate' this work ought to also consider Oasis and IETF
> specifications. Somehow triggers a crossposted thread on Mozilla lists "did
> we remove all the RDF/XML stuff yet?".
>
> December 2014, someone circulates some rules in N3 that show what a
> trivial problem this would be if only tools supported basic semantic Web
> meshup ideas. Heated discussion ensues.
>
> ... etc. </FICTION>
>
> Just to emphasize, this is all so obviously fictional. There's no way we'd
> get this much work done in 12 months.
>
> If anyone thinks a more positive timeline is possible, do please sketch
> one...
>
> Dan
>
>
>
>


-- 
Onderzoeker
+31(0)6 14576494
christophe.gueret@dans.knaw.nl

*Data Archiving and Networked Services (DANS)*
DANS bevordert duurzame toegang tot digitale onderzoeksgegevens.
Kijk op www.dans.knaw.nl voor meer informatie en contactgegevens.
DANS is een instituut van KNAW en NWO.

*Let's build a World Wide Semantic Web!*
http://worldwidesemanticweb.org/

*e-Humanities Group (KNAW)*
http://ehumanities.nl/