- From: John Arwe <johnarwe@us.ibm.com>
- Date: Fri, 31 May 2013 14:51:20 -0400
- To: Linked Data Platform Working Group <public-ldp-wg@w3.org>
- Message-ID: <OF52827018.E2DDF753-ON85257B7C.00661900-85257B7C.006794D7@us.ibm.com>
> > 4.1.5 "LDPRs MUST use the predicate rdf:type to represent the > > concept of type." > > > > Why does this have to be a MUST ? > > I don't think that is required to ensure that anything else works. > > I would say this is a SHOULD, or a best practice .. > > ? No objection to issue-ing it. Few things come to mind as background on the origin of this. I leave it to the WG for now to decide which is best in normative vs informative materials. 1: Some people started using dcterms:type, and we wanted LDP clients to have a single reliable (always there) way to know of an RDF resource was of the right type. While Dublin Core has words to discourage that for RDF resources (I know because I searched for an found them), there are many paths into Dublin Core and frankly the words are something you don't find unless you're either looking for them (most won't know to do so) or you're studying DC itself in depth (and honestly "no one" does this). I tell all our devs they have to read HTTP too, but I know they don't and I sympathize - time is a commodity and we all choose where to spend it, not always wisely in hindsight. 2: (this one is almost certainly deployment rather than normative) Some clients were [foolishly I know, but it happened] processing RDF/XML using non-RDF-aware XML processors and coding their processing to be dependent on abbreviated syntax (so root element qname, transformed to a URI == rdf:type URI). They did not fare well with servers that used rdf:Description root elements and hence "moved the type" to rdf:type. Nor would those clients behave reliably with >1 rdf:type. Others wrote code to assume rdf:Description-style and broke when abbreviated syntax was given them. Yes we tell them to use RDF libraries, but I'll tell you from personal experience not all products have that within their adoption cost envelope. I know of at least one product still using its own hand-crafted HTTP server (from pre-Apache days). Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
Received on Friday, 31 May 2013 18:51:54 UTC