Re: comments on Concepts

On 11/05/2013 06:25 AM, Guus Schreiber wrote:
>
>
> On 05-11-13 11:48, Markus Lanthaler wrote:
>> On Monday, November 04, 2013 8:06 PM, Guus Schreiber wrote:
>>> As preparation for working on the Primer I read through Concepts again.
>>> Her are some detailed editorial suggestions (all to be handled during
>>> CR except maybe the first one).
>>>
>>> Guus
>>>
>>> * Almost all references to Semantics are to the 2004 document (RDF-MT
>>> instead of RDF11-MT).
>>
>> Why not during CR? I think this isn't what was intended and should be 
>> fixed
>> ASAP.
>
> Markus,
>
> Yes, indeed, I had some hope for repairing it yesterday/today.
>

There's probably another hour or two -- I'm struggling with some other 
issues, making me regenerate all the documents.   (In concepts, I had to 
add a paragraph about why there's no implementation report.)

I changed the rdf-mt one.   Please check my change, if you get a 
chance.    And repair if necessary.

         -- Sandro

>>
>>
>>> * Sec. 1.8
>>> Suggest to include at least one syntax that handles RDF datasets, i.e.
>>> TriG.
>>
>> JSON-LD is already mentioned there. I think it would make sense to 
>> instead
>> remove some (yeah, RDF/XML e.g.). What about just keeping Turtle, 
>> RDFa, and
>> JSON-LD? Would be fine with adding TriG though.
>
> Would prefer dropping RDF/XML and adding TriG.
>
>>
>>
>>> * Secs. 3.3 & 5.2
>>> The namescace document http://www.w3.org/1999/02/22-rdf-syntax-ns does
>>> not contain these two new datatypes:
>>>     http://www.w3.org/1999/02/22-rdf-syntax-ns#langString
>>>     http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML
>
> I guess you missed the one above.
>
> Rest is fine, thx for the quick response.
> Guus
>
>>>
>>> * Sec. 3.6
>>> Should the reference to RDF Test Cases be updated?
>>
>> As already said, I still find this should be moved to Semantics as it 
>> isn't
>> needed in Concepts at all. The "apology" that RDF Test Cases needs it
>> (Concepts isn't testable) just underlines this. Same for section 4.1.
>>
>>
>>> * Sec. 4.2
>>> We probably had this discussion before, but I suggest to change
>>> "Primary resources" to "Primary Web resources", for clarity.
>>
>> Good catch. Would drop the Primary though as the term isn't clear and 
>> isn't
>> defined till section 6.
>>
>>
>>> * Sec. 5
>>> [[
>>>     Language-tagged strings have the datatype IRI
>>> http://www.w3.org/1999/02/22-rdf-syntax-ns#langString. No datatype is
>>> formally defined for this IRI because the definition of datatypes does
>>> not accommodate language tags in the lexical space.
>>> ]]
>>>
>>> The phrasing "No datatype is formally defined" is likely to confuse
>>> readers, given the first sentence. Suggest to rephrase such that it
>>> becomes clear the datatype mapping cannot be defined. The term
>>> "formally" also has a specific interpretation here which might not be
>>> clear to everyone.
>>
>> +1 but is it really true that it *cannot* be defined or is it just 
>> that we
>> decided to not define it? If the (optional) language tag would be 
>> taken into
>> consideration in the datatype mappings it would become possible... 
>> and in
>> practice I think that's what's done anyway, isn't it?
>>
>> This brings me to another point. The note in section 3.3 says:
>>
>>     Implementors might wish to note that language tags conform to
>>     the regular expression '@' [a-zA-Z]{1,8} ('-' [a-zA-Z0-9]{1,8})*
>>     before normalizing to lowercase.
>>
>> I don't think the "@" at the beginning is correct. That's just the 
>> separator
>> used in Turtle.
>>
>>
>>> * Sec. 5.1
>>> [[
>>>     The other built-in XML Schema datatypes are unsuitable for various
>>> reasons, and SHOULD NOT be used.
>>> ]]
>>>
>>> Explicate how this statement is related to the note just below it.
>>>
>>> * Sec. 6
>>> [[
>>>     Primary resources may have multiple representations that are made
>>> available via content negotiation [WEBARCH]. Fragments in RDF-bearing
>>> representations should be used in a way that is consistent with the
>>> semantics imposed by any non-RDF representations. For example, if the
>>> fragment chapter1 identifies a document section in an HTML
>>> representation of the primary resource, then the IRI <#chapter1> should
>>> be taken to denote that same section in all RDF-bearing representations
>>> of the same primary resource.
>>> ]]
>>>
>>> This paragraph has too much overlap with the previous one (subtle
>>> distinction, but this is likely to escape readers). Suggest to fold
>>> together.
>>
>> +1, what about removing the RDF/XML example (which explains the same 
>> thing
>> as the RDFa one) and instead adding a
>>
>> "Similarly, fragment identifiers should be used consistently in 
>> resources
>> with multiple representations that are made available via content
>> negotiation [WEBARCH]. For example, if the fragment chapter1 
>> identifies a
>> document section in an HTML representation of the primary resource, 
>> then the
>> IRI <#chapter1> should be taken to denote that same section in all
>> RDF-bearing representations of the same primary resource."
>>
>>
>>> * Appendix A
>>> The introduction of RDF datasets should be mentioned
>>
>> +1
>>
>>
>>> One more:
>>>
>>> * References
>>> [HTML-RDFA] needs to point to Rec version
>>
>> +1
>>
>>
>>
>> -- 
>> Markus Lanthaler
>> @markuslanthaler
>>
>
>

Received on Tuesday, 5 November 2013 12:18:39 UTC