RE: review of Research Drivers document

Hi Eric

I just want to clarify some of these issues before editing the document?

> [ 042. ]
> Summary: Text in section 2.4
> Raised By: Eric Miller
> Status: open
> Description: 2.4 (the first sentence is in fact not one) hmm... seems 
> like the first sentence in each paragraph in this section is a sub-point. 
> As its currently formatted this is confusing. 

Can you suggest a better way to format it? I copied this from the original
SIMILE proposal. 

Currently the sentences are summaries, then the paragraphs below describe
the sentences in more detail. One way to do this would be to make the
sentences section headings, but they seem a bit long for that. We could
summarize them to use them as section headings, but I like them as
statements. 

Another option would be to use a bulleted list, with the summary in bold or
in italics. However in the next issue you make a complaint about the
formatting of a bulletted list - is this a stylistic thing (I know some
people don't like lists used in this way) or is there another problem - is
it a browser related problem?

> [ 043. ]
> Summary: Formatting of section 3.1
> Raised By: Eric Miller
> Status: open
> Description: 3.1 Formatting of this section makes it difficult to read 
> and comment effectively. 

Not sure if this is a browser problem or a stylistic issue - can you
elaborate?

> [ 044. ]
> Summary: Use of the term instance validation
> Raised By: Eric Miller
> Status: open
> Description: 3.2.1 suggested title change from 
> s/Instance Validation/Semantic Validation 

I don't like this term. I don't think it is possible for computers to do
semantic validation as systems that are purely symbol processing cannot
determine whether a particular set of symbols is a valid encoding of the
real world. 

Of course, this depends on your definition of "semantic" so I guess the
first step to consensus here is to propose one? 

There are several we could use i.e. the lingustic definition used by John
Searle or the Tarksian definition, which seems closer to its usage by people
working on programming languages and the SW community. However the Tarskian
definition is quite different to common usage, so personally I prefer to
denote it with "formal semantics". 

> [ 045. ]
> Summary: Formatting in section 3.2.2
> Raised By: Eric Miller
> Status: open
> Description: 3.2.2 Formatting of this section makes it difficult to read
and comment effectively 

I guess this is the same as issue 43?

thanks in advance, br

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

> -----Original Message-----
> From: Eric Miller [mailto:em@w3.org]
> Sent: 04 April 2003 17:59
> To: www-rdf-dspace@w3.org
> Subject: review of Research Drivers document
> 
> 
> 
> This is a review of -
> 
> http://web.mit.edu/simile/www/resources/SIMILE%20Research%20Dr
> ivers%200.24.htm
> 
> http://web.mit.edu/simile/www/resources/issues.html gives 
> place holders
> to some of my comments, the following are a few more - 
> 
> 
> In general
> 
> s/semantic web/Semantic Web/
> 
> s/web/Web/
> 
> 
> Specific sections
> 
> 1.2
> 
> s/relationship between/relationship among/
> 
> 2.3
> 
> I'd add a patron/end-user perspective in terms of navigating, 
> accessing
> information in the challenges section.
> 
> 2.4
> 
> (the first sentence is in fact not one)
> 
> hmm... seems like the first sentence in each paragraph in this section
> is a sub-point. As its currently formated this is confusing.
> 
> 3.1 
> 
> Formatting of this section makes it difficult to read and comment
> effectively.
> 
> I'd a more general notion of annotation to be considered. 
> Human yes, but
> machine as well. This would tie in with section 4.8 in the
> data-mining/medline section.
> 
> 
> 3.2.1 
> 
> suggested title change from s/Instance Validation/Semantic Validation
> 
> 3.2.2
> 
> Formatting of this section makes it difficult to read and comment
> effectively
> 
> suggest s/Dublin Core/IMS/ as its more appropriate of an 
> example in this
> context
> 
> 3.2.3
> 
> I think its important to make the point clearer the option 
> that one new
> schemas are created, the option (and strong recommendation) 
> it to relate
> where appropriate new terms to existing.
> 
> 3.2.4
> 
> The Dublin Core Initiative has indeed agreed upon a set of formal and
> agreed upon relationships for relating resources
> 
> http://dublincore.org/dcregistry/detailServlet?reqType=detail&
> item=http%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2Frelation
> 
> btw... this service is one of several examples that are identified in
> section 4.4
> 
> the point being made in the paragraph is an important one, but the
> specific example is not correct.
> 
> 3.2.7
> 
> This is an important section but current version needs to be 
> flushed out
> a bit.
> 
> 3.2.8
> 
> I don't understand the goal for distinguishing between type and class.
> please elaborate or strike.
> 
> 3.5
> 
> This is an important section but current version needs to be 
> flushed out
> a bit.
> 
> 4.3.1
> 
> I'm willing to help sponsor this
> 
> Additionally I see this being an example of a distributed, 
> decentralized
> service.
> 
> 4.4
> 
> Suggest integrating RDF harvesting techniques (e.g.
> http://rdfschema.info/)
> 
> 4.6
> 
> I'm willing to help sponsor this
> 
> 4.9 
> 
> I think of this similar to section 4.2 (and examples of a larger
> collection description/management section?)
> 
> 
> -- 
> eric miller                              http://www.w3.org/people/em/
> semantic web activity lead               http://www.w3.org/2001/sw/
> w3c world wide web consortium            http://www.w3.org/
> 
>

Received on Wednesday, 9 April 2003 07:13:50 UTC