Re: Suggestions for Errata RDFa Core 1.1

Hello Shane,

thanks for your fast work and your comments.

I still have some comments on the earlier suggestions, I cut out the 
fixed things, so the quoted list below is much shorter now.
I kept the open issues, where you asked for input from the WG.

I have two more new things, that I discovered while proof reading my 
translation. They are kind of connected. 

7.2 Evaluation context, second list, item 5 
---
now:
... new subject value, which once calculated will set the parent 
subject 'property'...
--- 
suggestion:
... set the value for the parent subject
--- 
comment:
The use of the word 'property' is my concern. Property in RDFa is 
used as synonym to 'predicate', here it is used in the sense of the 
value for a subject.

Second:
7.2 Evaluation context, second list, item 6:
--- 
now:
A value for the current property value, the literal to use when 
creating triples that have a literal object, or IRI-s in the absence 
of @rel or @rev.

This sentence kills me.

1) Is it a value for a predicate in general? 
2) Is it a value for the attribute @property?
3) Is it a value for an object, that is a literal?
4) Is it a value for an object, that can be literal or IRI?

I would call 1) 'current predicate value'.
I would call 2) 'current property value'.
I would call 3) 'current object literal'
I would call 4) 'current object value' 

My ansers to the above: 
It cannot be 1) or 2), because they would require 
TERMorCURIEorAbsIRIs not a literal, like stated in the explanation.
It cannot be 3), because it could be IRIs also.
I could be 4), but the term 'current property value' doesn't really
allow that.

So what now?


Below are some more comments to the old stuff. Have to rush out now, 
some things below I'll finish commenting later.

Stefan


On 13 Apr 2013 at 12:34, Shane McCarron wrote:
> 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. 
> > Comment.
> 
> 
> > 5.0 Attributes and Syntax, definition vocab
> > A IRI
> > an IRI
> > The 'a' or 'an' is in small letters elsewhere in the document.
> Fixed
The PER doesn't show it as yet.

> > 7.6.1, third paragraph
> > ... allow the developer, if they would ...
developer, they
> > ... allow the developers, if they would ...
> > Similar like above with author.
> Fixed.
The PER doesn't show it as yet.


> > 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.
The PER doesn't show it as yet.


> > 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.

 
> > 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.
Ok, I might go to another court and file my case.
 

> > 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.
Fine, Terms Of Art shall be. Translators problem then. ;-)


> > 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., 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.
Yes, I like that one.

> > 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.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.


> > 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.
> 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.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?


> > 9, last note
> > entire note
> > ul
> > a nice list would make it better readable 
> Fixed.
Looks nice. There is the word 'Literal' in the last list item, it 
might like a small letter? All the other literals have small letters.
Except:
Serching the doc for literal I found in the table of contents:
8.3.1.2 Typed literals. Here it should be capital, because in the TOC 
all literals have capital letters.


> > 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.


> > 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.
Well, well, I shouldn't have said anything, now I have to translate 
one more production. Terms Of Art. Hm. Fine.


> > 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'.
Yes, I did use Entailment in my translation, I will keep it then and 
put a comment to explain it. 
But, if anyone comes up with some nicer Term Of Art for this, I'll be 
very happy.



-- 
Stefan Schumacher
Lonavala, Maharashtra, India
+91 9923670737

Received on Monday, 15 April 2013 08:53:47 UTC