RE: Pointers in RDF review

Hi Group,

Some comments below:

> Attached please find my edits and suggestions for the most 
> recent Pointers in RDF document at:
> 
> http://www.fundacionctic.org/uaw/ERT-WG/2009/EARL_draft.html
> 
> Some chief edits and questions:
> Note: For all of these major edits, the original remains in 
> comments prior to the edit. My suggestions begin with '<!-- 
> MAS -->'. Minor edits (e.g. spelling, typographical) are not noted.
> 
> 1. rewrote use cases section; still think we could use one or 
> two other use cases 

Looks good for me

> 2. rewrote description of Pointer class; 
> spec says this could be used directly but calls it abstract. 
> I suggest leaving it as abstract and requiring the use of 
> subclasses either in the specification or created elsewhere 
> in other vocabularies.

We need to decide on this. Actually, apparently there is no much value in using a generic Pointer that doesn't contribute any added meaning.

> Also, with this approach, there should 
> be a Related Classes section (see PointersGroup class, for 
> example) that points to subclasses in this spec. 
> If we want 
> to permit direct use of the Pointer class, then an example 
> should be provided.
> 3. rewrote descriptions of RelatedPointers and 
> EquivalentPointers classes

I suggest minor changes:

Related Pointers - a group of pointers to be grouped together for some purpose, indicating that the group members (presumably pointing to different parts of the document) have some relationship because they have a meaning as a whole. This is a subclass of the PointersGroup class

Equivalent Pointers - a group of pointers that point simoultaneously to the same part of the document, so that they can be considered equivalent. Put another way, each pointer in a set of pointers that are identified as equivalent must identify or pick out the same piece of content. This is a subclass of the PointersGroup class

> 4. didn't modify it, but recommend 
> that the description for SinglePointer look much like that 
> for Pointer class; make it abstract and require the use of 
> more specific subclasses

The current intention is to make it abstract, and the use of more specific subclasses is already required (using the must keyword)
My understanding of the generic vs. abstract issues is the following:

Pointer: Now is defined as generic, but may be better to make it abstract
SinglePointer and RangePointer: are both abstract
ExpressionPointer: is generic and should keep generic for flexibility

Will make the editorial changes needed to reflect this understanding.

> 5. in the example for 
> CharSnipetRangePointer, we refer to cnt:chars. Does this mean 
> that processors of Pointers in RDF must also know how to 
> process Representing Content in RDF? (May have already 
> discussed this but couldn't find anything in minutes.)

Haven't decided yet about the requiered conformance characteristics for Pointers capable tools, but at first instance it looks like it should be required.

> 6. Is 
> a pointer property along with a Pointer class going to be 
> confusing? Is there another name for the property (e.g. 
> memberPointer)?

Don't have any specials feelings with respect to this, if people think it's an improvement then it's ok for me

> 7. starting with Section 3 Properties, the 'in domain of' and 
> 'in range of' lists refer to earl:xxx QNames; should these be 
> ptr:xxx QNames?

Yes sure, I've changed it

> 8. rewrote abstract but still needs work

Not sure if so much emphasis on content definition is desirable, looks more like a Content in RDF abstract. Nevertheless it's an improvement with respect to the previous one.



Regards,
 CI.

____________________

Carlos Iglesias

Fundación CTIC
Parque Científico-Tecnológico de Gijón
33203 - Gijón, Asturias, España
teléfono: +34 984291212
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org

Received on Wednesday, 28 January 2009 12:20:38 UTC