AW: Library data is expressed primarily as text strings

Yes, I'd agree that "natural language" is a good choice here, and understandable for someone who is not a native speaker of English.

All the best,

Lars

  **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. ****
  **** Please note my new internet- and email-address. ****

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
l.svensson@dnb.de


> -----Ursprüngliche Nachricht-----
> Von: public-xg-lld-request@w3.org [mailto:public-xg-lld-request@w3.org]
> Im Auftrag von Peter Murray
> Gesendet: Dienstag, 6. September 2011 19:12
> An: public-xg-lld
> Betreff: Re: Library data is expressed primarily as text strings
> 
> I think "natural language" is a good choice of term.  I struggled a bit
> with a reply but kept getting tangled up in definitions.  "natural
> language" cuts through the confusion and tangle for me.  Others?
> 
> 
> Peter
> 
> 
> On Sep 6, 2011, at 12:29 PM, Karen Coyle wrote:
> > In other environments I have included the concept of "natural
> > language" to distinguish between these concepts. For most non-IT
> > people, "text" means "in a human language", and "text string" just
> > means a bit of human language. We refer to a book or article as being
> > "text." If I wish to refer to "strings" in the IT sense, I would say
> > "alphanumeric strings" or something of that nature.
> >
> > When I look up definitions of text I don't see anything that would
> > equate the term "text" with a URI. Even the definition of "formatted
> > text" [1] doesn't equate it with non-language strings.
> >
> > So maybe the problem here is with the use of "text strings" rather
> > than "text." Library data is primarily expressed as text -- that is,
> > as human language. The few uses of formatted data are either numeric
> > data (used mainly for cartographic materials) and codes (language
> > codes, codes for locations, etc.)
> >
> > kc
> >
> >
> > Quoting Carlo Meghini <carlo.meghini@isti.cnr.it>:
> >
> >> Corrected version of my previous message, apologies.
> >>
> >> Very interesting debate indeed.
> >>
> >> I am not sure I have followed all the developments, but here it
> >> seems to me that the problem is NOT the "text string" per sé. A URI
> >> (in its abstract syntax) is in fact a text string, and so is an
> >> ISBN. The difference between a URI and any other type of string is
> >> that a URI has a meaning associated to it, and this meaning allows
> >> an agent (for instance a piece of software), who knows there is a
> >> URI in a certain place, to do something with the URI (whether
> >> display it nicely or dereference it and get back a representation).
> >> So, a text string is fine, as long as the string conforms to a
> >> syntax with an associated semantics.
> >>
> >> Carlo
> >>
> >> On Sep 5, 2011, at 11:46 PM, Tom Baker wrote:
> >>
> >>> On Mon, Sep 05, 2011 at 11:41:51PM +0200, Antoine Isaac wrote:
> >>>>>> OK, I've tried it in
> >>>>>>
> http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Draft_issues_
> page_take2&diff=6212&oldid=6141
> >>>>>> (be careful, this diff includes quite some other changes,
> >>>>>> including a couple by Tom...)
> >>>>>
> >>>>> This pulls the two points together into one coherent point
> >>>>> quite efficiently.  Nicely done!
> >>>>>
> >>>>> One minor stylistic suggestion:
> >>>>>
> >>>>>  s/especially, changes/in particular, that changes/
> >>>>
> >>>> This reminds me too much of not elegant French constructions, I
> >>>> could not have thought of that :-)
> >>>> But if you think that's alright, feel free to implement it!
> >>>
> >>> DONE [1]...
> >>>
> >>> [1]
> >>>
> http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Draft_issues_
> page_take2&diff=6213&oldid=6212
> 
> --
> Peter Murray         Peter.Murray@lyrasis.org        tel:+1-678-235-
> 2955
> Ass't Director, Technology Services Development
> http://dltj.org/about/
> LYRASIS   --    Great Libraries. Strong Communities. Innovative
> Answers.
> The Disruptive Library Technology Jester
> http://dltj.org/
> Attrib-Noncomm-Share   http://creativecommons.org/licenses/by-nc-
> sa/2.5/
> 
>

Received on Tuesday, 6 September 2011 17:30:53 UTC