W3C home > Mailing lists > Public > public-rdf-wg@w3.org > December 2013

Re: Comments on Last-Call Working Draft of RDF 1.1 Semantics

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 12 Dec 2013 02:11:17 -0800
Cc: RDF WG <public-rdf-wg@w3.org>
Message-Id: <9A786F89-0257-4C18-9526-C5815B43E96F@ihmc.us>
To: Markus Lanthaler <markus.lanthaler@gmx.net>

On Dec 12, 2013, at 1:35 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Thursday, December 12, 2013 10:16 AM, Pat Hayes wrote:
>> ---------
>> Section 7
>> 
>> Datatypes are <a title="identify">identified</a> by IRIs.
>> Interpretations will vary according to which IRIs are recognized as
>> denoting datatypes. We describe this using a parameter D on simple
>> interpretations. where D is the set of <def>recognized</def> datatype
>> IRIs.
> 
> s/interpretations. where/interpretations, where/ (the comma)

Whoops. OK, done.
> 
> 
>> <p class="change note"> The previous version of this specification
>> defined the parameter D as a <a>datatype map</a> from IRIs to
>> datatypes, i.e. as a restricted kind of interpretation mapping. As the
>> current semantics presumes that a recognized IRI identifies a unique
>> datatype, this IRI-to-datatype mapping is globally unique and
>> externally specified, so we can freely abuse notation by thinking of D
> 
> s/so we can freely abuse notation by thinking of/so we can think of/ ????

Yes, probably better. "Abuse notation" is familiar math-talk but might confuse other readers. 

> 
> 
>> as either a set of IRIs or as a fixed datatype map. Formally, the
>> <def>datatype map</def> corresponding to the set D is the restriction
>> of a D-interpretation to the set D. Semantic extensions which are
>> stated in terms of conditions on datatype maps can be interpreted as
>> applying to this mapping.</p>
>> 
>> The exact mechanism by which an IRI identifies a datatype IRI is
>> considered to be external to the semantics, but the semantics presumes
>> that a recognized IRI identifies a unique datatype wherever it occurs.
>> RDF processors which are not able to determine which datatype is
>> identified by an IRI cannot recognize that IRI, and should treat any
>> literals with that IRI as their datatype IRI as unknown names.
>> 
>> [[Remove the second 'change note']]
>> 
>> ------
>> 
>> Two paragraphs later, add a [[sentence]] to the end of the paragraph:
> 
> The previous paragraph begins with
> 
>  "In summary: RDF literals are either language-tagged strings,
>   or datatyped literals"
> 
> which is inaccurate IMO. We discussed this before when I wanted to introduce
> a term for literals that are not langStrings. Here it bites ourselves.
> Language-tagged strings are datatyped literals

Weelll not *strictly* they aren't, because *strictly* rdf:langString is not a legal datatype. This is why I have to call it out as an exception in the semantics and give it its own special semantic condition, sigh. 

> , consequently the OR in this
> sentence is, strictly speaking, wrong. The simplest way out is probably to
> just remove the whole sentence.

But I will just omit the "datatyped", and then the contrast is between langString and the other cases which combine a datatype IRI with (just)  one string. OK?


> 
> 
>> .... RDF processors may recognize other datatype IRIs, but when other
>> datatype IRIs are recognized, the mapping between a recognized IRI and
> 
> s/a recognized IRI/the datatype IRI/ ???

Yes, better.
> 
> 
>> the datatype it refers to must be specified unambiguously, and must be
>> fixed during all RDF transformations or manipulations. [[In practice,
>> this can be achieved by the IRI linking to an external specification of
>> the datatype which describes both the components of the datatype itself
>> and the fact that IRI identifies the datatype, thereby fixing a value
>> of the <a>datatype map</a> of this IRI.]]
> 
> I don't think we need to add this sentence as we provide no mechanism to do
> so in a machine-processable way anyway.

True, but it was intended to be another piece of intuitive glue attaching "datatype map" firmly to "identifies", which was the real point of the changes. Unless you object to its content I would prefer to keep it. 

Pat


> 
> 
> Otherwise this looks good to me.
> 
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 12 December 2013 10:11:53 UTC

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