W3C home > Mailing lists > Public > public-rdf-comments@w3.org > May 2013

Re: Clarifying Temporal Datasets

From: James Leigh <james@3roundstones.com>
Date: Thu, 16 May 2013 13:08:47 -0400
Message-ID: <1368724127.1996.8.camel@james-PBL21>
To: Pat Hayes <phayes@ihmc.us>
Cc: Richard Cyganiak <richard@cyganiak.de>, public-rdf-comments <public-rdf-comments@w3.org>
On Thu, 2013-05-16 at 11:41 -0500, Pat Hayes wrote:
> On May 16, 2013, at 8:15 AM, James Leigh wrote:
> 
> > On Thu, 2013-05-16 at 10:10 +0100, Richard Cyganiak wrote:
> >> James,
> >> 
> >> ...
> >>> In section 5.5 The Value Corresponding to a Literal, It says they "MUST
> >>> accept ill-typed literals". I believe that should be changes to "SHOULD
> >>> accept ill-typed literals", since earlier it says they SHOULD NOT reject
> >>> them.
> >> 
> >> Sorry, where does it say that they SHOULD NOT reject them?
> >> 
> > 
> > In section 5.4 Datatype IRIs, "Applications may give a warning message
> > if they are unable to determine the referent of an IRI used in a typed
> > literal, but they should not reject such RDF as either a syntactic or
> > semantic error."
> > 
> > I believe MUST is too strong either way, as many RDBMS database have a
> > limited set of data types, but one should still be able to use a
> > domain-specific RDBMS schema to store RDF data.
> > 
> 
> I believe MUST is appropriate, but I don't understand why you feel that this would be a problem for RDBMS databases. Yes, one should be able to use a domain-specific schema to store RDF data. That is why other RDF engines MUST not reject data typed with that schema even when they don't know what schema it was. 
> 
> Note, this MUST only says that it should not be rejected as bad RDF. It might be rejected on other grounds, and RDF engines can issue a warning or flag it. What they are not allowed to do is report it back as badly formed RDF which does not conform to the RDF spec.. 
> 

That sounds fine wrt MUST wording. Thanks for clarifying.

James
Received on Thursday, 16 May 2013 17:09:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:56 UTC