W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2013

Re: Suggestions for Errata RDFa Core 1.1

From: Shane McCarron <ahby@aptest.com>
Date: Sat, 13 Apr 2013 12:34:29 -0500
Message-ID: <CAOk_reFmEMBy+ehBZ++V1ONtee9_Z90okBRND50r1xAoguzcHA@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Stefan Schumacher <stefan@duckflight.de>, RDFa WG <public-rdfa-wg@w3.org>
I have gone through your comments.  Thanks so much for the feedback!   My
replies are in-line.  An updated draft is available at
http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html

There are a couple of comments were I could use responses.

Suggested Errata
> for RDFa Core 1.1
> http://www.w3.org/TR/2012/REC-rdfa-core-20120607
> Assumed Errors
> Location in the document
> Text in the current document.
> Suggested text for errata. You might add this, but I don't think, it is
> necessary. (Omit me too, if you like.)
> Comment.
> Status of the document, first ol, first li
> First list item is missing a "." at the end.
>

Fixed


> Status of the document, to the end of the section
> There is a more complete list of changes
> There is a complete list of changes /or/ There is a list that describes
> more changes
> If something is complete, it can not be more complete, otherwise it
> wouldn't have been complete before, so either it is a complete list, if all
> changes are covered, or it is a "longer" list if it is not
> complete/exhaustive.
>

Changed.


> 3.2 Triples, first sentence
> The first is the subject of the triple, and is what we are making our
> statements about.
> The first is the subject of the triple, and is what we are making our
> statement about.
> The texts speaks about THE triple, so it is only one statement, I would
> use the singular.
>

Fixed.


> 3.3 IRI references, last paragraph, last sentence
> <dfn title="iri-reference" id="T-iri-reference">IRI references.</dfn>
> <dfn title="iri-reference" id="T-iri-reference">IRI references</dfn>.
> The '.' at the end is inside of the dfn tag. On the other hand, the
> definition for IRI is not made in this document. Maybe use a different way
> to emphasize/mark up.
>

Fixed punctuation.


> 4.2 RDFa Host Language Conformance, first li item, note
> througout
> throughout
> Typo
>

Fixed


> 4.2 und 4.3
> (W ... ).
> (W ... .)
> Full stop before ')', full sentence in (), so full stop inside (... .)
>

Fixed


> 5.0 Attributes and Syntax, definition vocab
> A IRI
> an IRI
> The 'a' or 'an' is in small letters elsewhere in the document.
>

Fixed


> 7.3 Chaining, last paragraph before 7.4
> The subject for the 'German Empire' would remain Albert Einstein (and that
> would, of course, be an error).
> The subject for 'the German Empire' would remain Albert Einstein (and that
> would, of course, be an error).
> The subject for (the object) 'German Empire' ist Albert Einstein, the
> predicate is given via property="dbp:birhtplace". Wrong would be, if Albert
> Einstein would be the subject for the object 'the German Empire' with the
> property="dbp:conventionalLongName". I think, the apostroph needs to be
> shifted.
> Actually there is only 'German_Empire' and 'the German Empire' in the
> example, so it should be precisely used like in the example to avoid
> confusion. The confusion starts in an example further above, where 'German
> Empire' is used for http://dbpedia.org/resource/German_Empire, so the
> reader might walk into this trap. Maybe it would be better to use
> dbr:German_Empire and dbr:Switzerland in all the explanations for the
> examples instead of the commonly associated names like German Empire and
> Switzerland and so on.
>

Fixed the apostrophe


> 7.4.2, in the examples
> ... an author might do this ... they would do this ... The author could ...
> ... an author might do this ... the author would do this ... The author
> could ...
> First example uses author, second example refers to the autor in first
> example, but uses they. I would keep it simple and either use author or
> authors throughout the document. Author is nice for translations, please,
> never change it to publisher like in other specs.
>

Removed use of 'they'


> 7.5 Sequence, first note
> ... bnode' It is ...
> ... bnode'. It is ...
> Missing '.'
>

Fixed.


> 7.6.1, third paragraph
> ... allow the developer, if they would ...
> ... allow the developers, if they would ...
> Similar like above with author.
>

Fixed.


> 7.6.1, last paragraph
> An web service ...
> A web service ...
> An to A
>

Fixed.


> 7.6.1, last paragraph
> ... allow the caller to specify if they ...
> 1. ... allow the caller to specify if he/she ...
> 2. ... allow the callers to specify if they ...
> Similar like above.
>

Fixed.


> 8.1.1.2, header for last example
> which should generate the following triples:
> which should generate the following triple:
> Only one triple generated.
>

Fixed.


> 8.1.1.4.1
> the first group are set to refer to the @about that contains them:
> the statements in the first group refer to the (attribute) @about that
> contains them:
> a group is, statements are. See next item also.
>

Fixed.


> 8.1.1.4.1
> whilst the second group refer to the @resource that contains them:
> whilst the statements of the second group refer to ...
> Similar like above, a group refers, statements refer.
>

Fixed.


> 8.2, to the end of the section
> The entire set of triples that an RDFa Processor should generate are as
> follows:
> The entire set of triples that an RDFa Processor should generate is as
> follows:
> The entire set ... is, the 'are' problably derives from triples, in that
> case you could write something like: All triples that an RDFa processor
> should generate are as follows:
>

Fixed.


> 8.3, last paragraph
> A IRI resource object
> An IRI resource object
> A change to An
>

Fixed.


> 8.3.1.3 XML Literals
> an empty @datatype value can be used create a plain literal
> an empty @datatype value can be used 'to' create a plain literal
> 'to' missing
>

Fixed.


> 8.3.1.3 XML Literals
> Although the rendering of this page has highlighted the term the user
> searched for, setting @datatype to nothing ensures that the data is
> interpreted as a plain literal, giving the following triples:
> 1. 'Rendering of this ...searched for. Setting ... *Skip 'Although', make
> two sentences.*
> 2. setting @datatype to 'an empty string'
> 3. ... giving the following 'triple'. *Only one triple in the example.*
>

Fixed.


> 8.3.2
> <span>@typeof</span>
> <span class="aref">@typeof</span>
> The other attributes have the class 'aref', looks like it got lost here,
> so it has a different appearance in the document.
>

Fixed.


> B.1
> foaf IRI
> FOAF IRI
> FOAF is otherwise used throughout the spec.
>

Fixed.


> Location in the document
> Text in the current document.
> Suggested text for errata. You might add this, but I don't think, it is
> necessary. (Omit me too, if you like.)
> Comment.
> Suggested alternative text
> Abstract
> ... enabling structured search and sharing.
> ... enabling structured search and sharing with the described RDFa
> information.
> I was not sure if "structured" refers to sharing too. Structured sharing
> would mean to share things with the structure behind? I just cannot connect
> to "structured sharing". If structure is only referring to search, I would
> emphasize that it is sharing the picture with the RDFa information.
>

I was afraid to mess with this.



> 2. Syntax Overview, last NOTE
> In some of the examples below we have used IRIs with fragment identifiers
> that are local to the document containing the RDFa fragment identifiers
> shown (e.g., 'about="#me"').
> In some of the examples below we have used IRIs with 'local' fragment
> identifiers (that point to items/fragments inside of the same document) (e.g.,
> 'about="#me"').
> From my point of view, the expanation of a local fragment identifier in
> the current version of the sentence makes more confusion than just saying,
> 'local' fragment indentifiers are used. That's it. The rest of the sentence
> is saying the same, but makes it confusing.
>

This language came from the W3C TAG and I don't dare change it.



> 3.2
> RDFa has complete support for internationalized characters. This includes
> internationalized characters in the subject, property and object location.
> RDFa supports (all) internationalized characters for the subject, the
> 'predicate' and the object.
> I would make the sentence short. Additionally use 'predicate' instead of
> 'property' to use one term throughout the spec only. The note above says,
> that property is suggested to replace predicate, but at present, predicate
> is the used term.
>

Done


> 3.6, last paragraph
> in reality
> reality? any other word? actual processing? real processing environment?
> Any native english speaker please.
>

Done


> 4.2 RDFa Host Language Conformance
> All of the facilities required ...
> All requirements of this specification have to be included ...
> This is just a translator request, facilities can mean anything and is
> horrible to translate.
>

This language is historical - facilities is a term of art in the standards
industry.  I don't have an appropriate substitution.


> 4.2, note
> ... that are commonly used througout the Host Language.
> ... that are commonly used throughout documents written in the Host
> Language.
>

Changed to 'that are commonly used throughout the content model of the Host
Language'


> .
> 6. CURIE Syntax Definition
> Otherwise, if a CURIE consists of a non-empty prefix and reference
> Otherwise, if a CURIE consists of a non-empty prefix and a reference
> In the first li, there is an a, in this one not, it could mean, that the
> reference is also not-empty. Might be better to keep it consistent with the
> first li.
>

Fixed.


> 6., note, The production safe curie ...
> cannot
> must not
> Is this cannot used in the meaning of 'should not' or 'must not'?
>

Neither.  This is not a conformance requirement.  It literally means 'it is
impossible for this to happen'.  As in it is a logical impossibility.


> 7.2 and maybe other sections
> during the course of processing
> during/while processing
> during or while already say it is between the start and the end of
> processing. This 'course' is 'extra' and it complicates the translation
> (just a little bit).
>

This means 'things change over time'.  It is a subtle but important
concept.  I am reluctant to change it


> 7.2, first list, last list item
> a value to use as the prefix IRI when an undefined term
> unprefixed term
> ?
>

No.  What this means a term that is unknown to the processor.  I made a
change to clarify that.


> 7.5
> although the evaluation context used 'for each set of rules' will be based
> on previous rules that may have been applied.
> 'every cycle/run through the set of rules'
> (an evaluation context based on the resulting evaluation context from the
> last run will be used)
> I would prefer, if it is clearer, that the processing rules are applied
> again and again for each element, and that the evaluation context normally
> changes after each run. My suggestion surely needs some proper english, I
> put that on you. :-)
>

I appreciate that the language in this section is stilted.  But it is
actually the only important part of this document as far as I am concerned.
  I don't dare change any of the text without a full review by the working
group.



> 7.5, Rule 9, first blue box
> If the element contains both the @inlist and the @rel attributes: ...
> I would suggest a line break after the colon. Then indent the next line.
> I think, that would make it easier to follow.
>

Actually that colon should not have been there.  I removed it.


> 7.5 source code of the steps
> There is an HTML comment in the source code for almost every step, so you
> can find the steps faster, that stops after step 10.
> Nice editing feature to have for all steps up to 14. Sorry for bringing in
> smallest things you can't even see in the browser view.
>

Fixed.


> 7.6.1
> An web service RDFa Processor is defined as any RDFa Processor that is
> capable of processing a document 'by performing an HTTP GET, POST or
> similar action on an RDFa Processor IRI'.
> no suggestion yet
> What is an RDFa Processor IRI?
> 1. The IRI where the RDFa Processor is located? Or
> 2. the IRI that the Processor should look up and process?
> I wouldn't call the second IRI 'RDFa Processor IRI' it is more an 'RDFa
> document IRI'.
> I would say, an RDF processor is reachable under an 'RDFa Processor IRI'.
> For my translation, it would be nice if I get a response to this issue.
>

It is the IRI for an RDFa Processor - in other words, the address someone
would use to query the processor via the web and extract triples from an
RDFa document.

And a typo: An web server to A web server
>

Didn't find this one - must have been fixed earlier.


> 8.2, one of the examples
> To illustrate, to indicate that Spinoza influenced
> Sugestion 1: To indicate that Spinoza influenced
> Suggestion 2: The following markup illustrates, how to indicate, that
> Spinoza ... .
> 1: Remove 'To illustrate'. This is an example, examples are anyway 'to
> illustrate'. 'To illustrate, to indicate' makes the text less readable and
> more difficult to translate. Or better:
> 2: merge the illustrate with markup from the end and have a nice flow of
> words.
>

Fixed.


> 8.3
> A literal object can be set by using @property to express a predicate, and
> then using either @content, or the inline text of the element that
> @property is on.
> A literal object can be set by @content or the inline text of the element,
> if @property is used to express a predicate.
> 'Using @content' is not precise, say what @content and the inline text do:
> they provide the literal.
> Little brainstorming:
> In the actual version I just read 'a literal object can be set by using
> @property', I just ignore the rest, and my mind is fixed, that @property
> will set my literal. Ups.
> So if you bring it ito some other order, it is easier to understand.
> Further:
> I think in the suggestion it is clear, that it is the element, that
> @property is on, that provides the literal (either through @content or
> inline text). So no need to explicitly say that (and make the sentence more
> complicated to understand).
>

Made a change that helps.   Some.


> 8.3, last paragraph
> Alternatively, the @property can also be used to define an IRI resource,
> in the presence of an @href, @resource, or @src and in the absence ... .
> Alternatively, @property can be used to define an IRI resource; this
> requires the presence of ... and requires the absence of ... .
> This would give the sentence a sharper edge.
>

Fixed.


> Skip 'the' before property, otherwise write it in full 'the attribute'.
> Skip 'also', alternatively says that already.
> Another idea would be to repeat, that @resource, @href, or @src are
> resource attributes (to burn it into the readers mind):
> ... in the presence of one the resource attributes @resource, @href, or
> @src ... ; and keep this order like it is in section 5.1 for
> into-brain-burning.
>

Fixed some.



> 8.3.1.2 Typed Literals
> The triples that this markup generates include the datatype ...
> The triple that this markup generates includes the datatype ...
> Just one triple is created in the example below.
>

Fixed.


> 8.3.1.3 XML Literals
> RDFa therefore supports the use of normal markup to express XML literals
> none
> What is normal markup? Could be more precise.
>

Changed a bit.


> 8.4, before second example
> RDF has a set of predefined predicates that have an agreed-upon semantics
> of order.
> ... that follow (a) defined/given semantic(s?) of order.
> 1. an ... semantics, either a semantic or just semantics, where I think
> singular is fine.
> 2. agreed-upon, after you agreed upon that, you might have defined it, so
> it is given now? Make it easy to translate, please. :-)
> 3. Do you really say semantics of order?
>

I don't care touch this - anyone else have an opinion?


> 8.4 List Generation
> the list is used with the common predicate with the common subject
> the list is used with the common predicate and subject
> If the suggestion is not fine, maybe an 'and' between 'with the common
> predicate (and) with the common subject'
>

Fixed.


> 9, last note
> entire note
> ul
> a nice list would make it better readable
>

Fixed.


> 10.1.1
> Last paragraph ist not enclosed in p tag
> p
> Enclose it in a paragraph.
>

Fixed.


> 10.1.1
> 1. RDFa-Vokabular-Entailment considers only the entailment on individuals
> 2. not on the relationships that can be deduced on the properties or the
> classes themselves
> none
> 1. Individuals, what is that? Is there any precise RDFish term, that could
> be used?
> 2. deduce on? Sorry, I don't understand, please help me translate. :-)
>

I can't really comment on this.  Anyone else?



> Location in the document
> For each IRI being the object of a triple in the output graph with the
> subject being the current document (base) IRI and the property being
> rdfa:usesVocabulary, that IRI is dereferenced.
> If there are one or more triples in the output graph, that contain a
> subject being the current document (base), the property (better:
> predicate?) rdfa:usesVocabulary, and an object being an IRI, the IRI of
> each triple is dereferenced.
> From my point of view it is written a bit confusing, from the context it
> is clear, but the structure of the sentence doesn't support, that the
> subject and property are 'in the triple'. In the suggestion, the flow of
> the sentence brings up a triple, inside a subject, property (what could be
> also referred to as predicate to keep the spec in one voice), and object.
> Plain structure.
>

I agree that this sentence is hard to parse.  I have taken a shot at
restructuring it.



> 10.1
> Note that if, in the second step, a particular vocabulary is serialized in
> RDFa, that particular graph is not expected to undergo any vocabulary
> expansion on its own.
> 1. graph replace with vocabulary graph
> 2. see comment
> How can a graph undergo something on its own, a graph is a file, not a
> processor, is there any detailed description with precise words for this
> whole sentence?
>

A graph is a concept - not a file.


> Location in the document
> Text in the current document.
> Suggested text for errata. You might add this, but I don't think, it is
> necessary. (Omit me too, if you like.)
> Comment.
> General comments
> Throughout the doc
> production vs. definition
> definition
> In some parts of the document, production is used for definitions:
> 'term ::= NCNameStartChar termChar*'
> In 7.4.3 'definition' is used in a note for the same 'thing'. Is there
> anything, that would force the use of the term 'production' for this?
> Production is not nice to translate, and if it is in deed a definition, it
> would be nice to just call it definition. I'd like to see that in an
> editors guideline for the use of terms in all W3C specs. :-) Is there
> anything like that?
>

'Production' is a term of art.  It is used in many W3C specs.  We really
should use it consistently.  I changed 'definition' to production in one
place.  There is no other suitable term that I know of.  Sorry.



> Throughout the doc
> entailment
> no idea
> Entailment is a pretty tough word, it can be used in different ways, the
> translation into German is a mess. Is there any other nice english word,
> that would do, is more precise and is expected to have a nice translation?
>

Uggh.  This is something from the Semantic Web community, and I can't speak
to it. I don't think it has a translation that makes any sense  I would
honestly just use the word 'Entailment'.


> Throughout the examples
> Sometimes there are '.' in the examples, after that the next sentence
> starts with a capital letter, sometimes no '.' and captital letters,
> sometimes small letters.
> Try to keep it consistent. Either no '.' or put it everywhere.


I assume you mean punctuation at the end of sentences.  A more consistent
style in examples would be nice.  In some cases examples are literal data
and it would be bad to change it.  I will take a spin through






On Sat, Apr 6, 2013 at 9:13 PM, Ivan Herman <ivan@w3.org> wrote:

>
>
> On 7 Apr 2013, at 03:21, Shane McCarron <ahby@aptest.com> wrote:
>
> Thanks for this detailed list.  I will take some time to look it over in
> the coming days.  Manu and Ivan, I assume editorial changes like this are
> in scope?
>
>
> Yes.
>
> Ivan
>
>
>
> On Sat, Apr 6, 2013 at 9:36 AM, Stefan Schumacher <stefan@duckflight.de>wrote:
>
>> Hello RDFa Working Group,
>>
>> while translating the RDFa Core 1.1 spec, I found some things, that
>> might need a look at. Mostly just small things.
>>
>> I attached an HTML file with all the suggestions I have. Ivan
>> mentioned that there might be a PER coming for some RDFa specs, so
>> this might help a bit.
>>
>> I am not sure, if the attachment is delivered properly, if not,
>> please advise me, how to send the HTML file again.
>>
>> There are two questions inside, that would help my translation, so if
>> I don't hear anything, I might bother you in a few days.
>>
>> So long
>> Stefan
>>
>>
>>
>> --
>> Stefan Schumacher
>> Lonavala, Maharashtra, India
>> +91 9923670737
>>
>>
>> The following section of this message contains a file attachment
>> prepared for transmission using the Internet MIME message format.
>> If you are using Pegasus Mail, or any other MIME-compliant system,
>> you should be able to save it or view it from within your mailer.
>> If you cannot, please ask your system administrator for assistance.
>>
>>    ---- File information -----------
>>      File:  Suggested_Errata_RDFa_Core_1_1.html
>>      Date:  6 Apr 2013, 19:53
>>      Size:  25921 bytes.
>>      Type:  Unknown
>>
>>
>
>
> --
> Shane P. McCarron
> Managing Director, Applied Testing and Technology, Inc.
>
>


-- 
Shane P. McCarron
Managing Director, Applied Testing and Technology, Inc.
Received on Saturday, 13 April 2013 17:34:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:34 UTC