Re: Comments on abstract syntax document

Hi Simon,

Thanks for your comments. Responses inline.

On 11 Mar 2012, at 00:57, Simon Reinhardt wrote:
> Property is defined twice and the two definitions seem to be incompatible.
> Under "1.2 Resources and Statements" it says "The predicate itself is an IRI and denotes a binary relation, also known as a property." (#dfn-property)
> Under "4.1 Triples" it says "The predicate is also known as the property of the triple." (#dfn-property-1)
> Either the predicate denotes the property or it is the property.

Good catch. The first definition is based on what's said in RDF Semantics, and it indeed disagrees with what we later say in RDF Concepts. This looks like a contradiction between the two specs. I'll raise this with the WG, suggesting that the second definition should be removed. (I think it is clear that a class is not an IRI; it is denoted by an IRI. It should be the same for properties.)

> Under "4.3 Literals" it says "a lexical form being a Unicode [UNICODE] string, which should be in Normal Form C [NFC]".
> The "should" lost its markup, so <em class="rfc2119" title="should">should</em>.

Fixed.

> Under "5.4 The Value Corresponding to a Literal" it says "If the literal's datatype IRI is not in the datatype map, then the literal value is not defined by this specification."
> Which datatype map is that? It says "the" so it must be a specific one rather than any.

[[
A datatype map is an implementation-defined set of <IRI, datatype> pairs such that…
]]
http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#dfn-datatype-map

“Implementation-defined” means that the datatype map is defined by the implementation.

I have changed the sentence you quoted from 5.4 as follows, to make this more explict:

[[
If the literal's datatype IRI is not in the implementation-defined datatype map, then the literal value is not defined by this specification.
]]

> Under "7. Fragment Identifiers" it says "For example, if the fragment #chapter1 identifies a document section in an HTML representation of a primary resource, then #chapter1 should be taken to denote that same section in all RDF-bearing representations of the same primary resource." and "Likewise, RDF graphs embedded in non-RDF representations with mechanism such as RDFa [RDFA-PRIMER] should use fragment identifiers consistently with the semantics imposed by the host language."
> However I can just use a fragment identifier to denote arbitrary things both in RDFa in HTML and in, say, a Turtle document at a URL which can also conneg to HTML, as long as it is not used as an id on an element in the HTML, right?

Correct.

> Could this section explicitly state that? Because I think that was one of the concerns people had about using them.

The statement you'd like to see is something like this, right?

“If a particular fragment identifier is undefined in one representation, then this in no way constrains its use in other representations.”

This is already said in RFC 3986 (the URI spec):

[[
   If the
   primary resource has multiple representations, as is often the case
   for resources whose representation is selected based on attributes of
   the retrieval request (a.k.a., content negotiation), then whatever is
   identified by the fragment should be consistent across all of those
   representations.  Each representation should either define the
   fragment so that it corresponds to the same secondary resource,
   regardless of how it is represented, or should leave the fragment
   undefined (i.e., not found).
]]
http://tools.ietf.org/html/rfc3986#section-3.5

Given that there's already a normative reference for it (and we already have a link to it in the text), and given that it's a general thing that applies to any representation format, I think it shouldn't be repeated in RDF Concepts.

Thanks again for your comments!

Richard

Received on Thursday, 26 April 2012 00:00:59 UTC