HCLS IG Meeting Record 16 July 2007


                                    HCLS IG

16 Jul 2007

   See also: [2]IRC log


          susie, Chimezie_Ogbuji, Don_Doherty, Khalid, BillBug, JonathanR,
          AlanR, JeremyZucker, VijayBuluse, StevenDobson, ericP,
          ElizabethWu, PaoloCiccarese, Sudeshna, Marc-AleXandreNolin,
          DanielRuben, ericN, EricNeuman




     * [3]Topics
         1. [4]Review reasons for putting effort into this project
         2. [5]Discuss process (consensus and closure)
     * [6]Summary of Action Items

   <Don> FYI, the phone signal from MIT is cutting in and out.

   <Don> Mostly out.

   Yeah - Don's right. I'm getting every 10th word. :-(

   <chimezie> yes, it is getting worse

   <Don> Anyone from MIT on the IRC?

   <jar286> I am.

   <ericP> Zakim MIT346 holds JonathanR, AlanR, JeremyZucker, VijayBuluse,
   StevenDobson, ericP, ElizabethWu, PaoloCiccarese, Sudeshna

   <Don> Is anyone looking at the signal problem?

   <ericP> oops sorry, don.

   <ericP> hmm, not a problem we usually have

   Sounds like whoever - or whatever phone - is dailed in, has a signal
   noise squelching function running that is just way to sensitive to the
   breaks between words when people talk. Dialing in with another phone/or
   IP telephony app would probably fix it.

   <chimezie> yes, plz

   <Don> Eric, it's not just me.

   <Don> Everyone is having trouble hearing.

   <Don> Still the case.

   <Don> John is coming in.

   Actually, you are all coming through fine, now.

   <Don> Sounds good now.

   <Don> Thank you!

Review reasons for putting effort into this project

   <ericP> jar286: is the interest group that same as the mailing list?

   <ericP> [heads nod]

   <Bio2RDF> My full name is Marc-Aleandre Nolin

   <Bio2RDF> oups.. miss an X ... Marc-AleXandre Nolin

   <ericP> Sudeshna: do you have a scope of Bio entities in the domain of

   <ericP> Bio2RDF, could you try "/nick Marc-Aleandre" ?

   <Jeremy> Agenda: 1. Review reasons for putting effort into this project

   Given "Description" is in the name of RDF, it seems reasonable to use
   the word, so long as we are clear what associated information is
   included in "Description" - IDs, Definitions, relations to other
   resources, etc.

   Resource Description Framework (RDF)

   <Jeremy> 1. Review reasons for putting effort into this project

   <Jeremy> - use same URI for same thing

   <Jeremy> - clarity

   <Jeremy> - non-punning

   <Jeremy> - reusing URI's for another purpose is worse than breaking

   <Jeremy> - have a story about accessing

   <Jeremy> "description of x" =def RDF statements that describe x.

   <Jeremy> (definition, identification, specification, documentation...)

   <Jeremy> (also need to get at other statements about it.)

   <chimezie> aren't "descriptions" the larger group of such 'statements',
   with a specific subset which provides formal definitions?

   <khalid_> Hi everybody

   <chimezie> hello

   <Jeremy> One example of a complicated thing that can be described with
   URI's is Glycolysis:

   <Jeremy> If you click on the BioPAX format button, you get the RDF
   associated with it.

   would you please post the "glucose" link to the list?

   <Marc-Alexandre> hie eric, francois belleau with marc-a

   <Marc-Alexandre> can you push the agenda on the irc

Discuss process (consensus and closure)

   I agree with Chimezie's comment above - descriptions could subsume
   definitions as well as other things such as IDs, relations, etc..

   Welcome, Scott.

   <mscottm> Thanks Bill. Still waiting for my other half to get home from
   a conference to help take care of the kids but lurking here now.

   Ah, yes - it's evening there for you, Scott. I forgot.

   <jar286> editor keeps coming back to the working group with revisions

   <jar286> they ask for revisions, or give go ahead to publish

   <ericP> alanr: what would make Pfizer adopt the recommendations of this
   URI BP document?

   <jar286> meeting of hcls needs to approve publication of each draft

   <ericP> StevenDobson: when some implementor adopts or supports it

   <ericP> alanr: like who?

   <ericP> VijayBuluse: ACCELYRS

   <jar286> group recommends that editor maintain an issues list

   Definitions + examples is the ONLY way to avoid confusion, as the
   examples help to constrain the meaning of the collection of words you
   call a definition, although in OWA the definition can still be easily
   misinterpretted. At least a good collection of non-overlapping examples
   can HELP to avoid misinterpretation of a definition by itself.

   To follow on Alan's comment on OBI - it's really in OBI and the Basic
   Formal Ontology (BFO), as that foundation needs to support those
   classes we define in OBI.

   I'd be careful of using version as given in LSID, as this is probably
   THE most problematic aspect of the LSID spec - and the one that is
   interpreted in a rather divergent way by those who've actually
   implemented an "LSID"-based respository.

   <jar286> ok

   <jar286> EN: Clear policy expression is VERY IMPORTANT. (for
   versioning, etc)

   <jar286> AR: OBO has a reasonable process for ontology evolution.

   <jar286> Eric N says HCLS is likely to be extended to end of year.

   Guidelines/requirements for published versioning/update policy are
   critical. I can see how one could create guidelines for such policies,
   where we at least say you must specify what you MEAN by 'version',
   'variant', 'dynamic content', 'stable content', and 'unchanging
   document' (as you've outlined them, JAR). Recommendation would include
   specifying a range for the temporal boundaries for...

   scribe: each of these properites.

   We'd have to provide some examples - hopefully a range of examples for
   each property.

   <ericP> ACTION: EricN to see if terms from URI Recommendations Document
   adequately support [a strawman] version and revision ontology, i.e. can
   you express policies [recorded in

   LSID has partly suffered by being so highly constrained in terms of its
   versioning policy. I could see 'version' as defined by LSID as being an
   ideal to work toward. In practice, people who have implemented LSIDs
   have implemented version differently. It would help in any URI policy
   HCLS IG publishes to explicity declare we recognize at this point in
   time - given how much the technology...

   scribe: and the requirements are still in flux - there is a need to
   constrain the RANGE of what is acceptable for 'version' - give clear
   examples of versions - and provide short pros & cons on each example
   given the consensus HCLS IG understanding of how we would like to
   compute on these resources.

   <ericP> ACTION: ericP to determin HCLS charter close [recorded in

   Jonathan - one practice that MIGHT help to make your definitions more
   clear - and make it easier for people to come to consensus on them -
   would be to use DC Metadata Elements in the body of the definitions. A
   lot of work went into the creation of DC, and we MIGHT be able to gain
   a further level of clarity and agreement by leaning on CD Metadata
   element definitions and examples. This is...

   scribe: just a suggestion. If you think going out to DC metadata only
   complicates and further obscures the defs, then skip it.

   remember - if you are thinking of the publishing world, when they think
   of persistent references, they think of DOI - which I don't think we
   have the time to sort through before HCLS IG runs out.

   Is anyone reading the IRC?

   Can it be projected on the board so remote folks can add something to
   the discussion?

   <Marc-Alexandre> Im reading it, but Im not in the MIT 346 room

   <mscottm> I'm reading too..

   One question on Jonathan's OK URI - he mentions 'stable' -"...but the
   URI's intended meaning must remain consistent." Constant and consistent
   mean something different. For LSID's, meaning AND content must remain
   constant. I'd think for an OK URI, we should at least say the meaning
   remains constant (even if not EVERY bit in the content is stable).

   <Marc-Alexandre> having a set of rules that anyone can simply apply
   when building their URI is what Bio2RDF is telling from the Banff

   Sorry - I meant to say even if EVERY bit in the content is NOT stable.

   Marc - did you mean at the Banff Conference, the Bio2RDF group stated
   they were committed to establishing a set of rules anyone can simply
   apply when building their URIs?

   <Marc-Alexandre> yes, we said, that Purl or HCLS have a set of rules
   about how to build URI (like, all lowercase, namespaces followed by a
   semi-colon then the id then a dot then the version, etc)

   <Marc-Alexandre> ok... it's not all the rules... but somes rules that
   can be uses

   That would be wonderful, Marc. To date, mostly what we've been doing on
   the HCLS IG list is to debate the issue, which is partly why Jonathan
   is so anxious for us to reach some consensus and publish it.

   In the end, whatever "ontology" we use for defining URI-related
   policies should try to re-use DC metadata where ever practical, and
   stay compatible with the SKOS effort that Daniel Rubin and Alan
   Ruttenberg are contributing to.

   <Marc-Alexandre> I've elaborate a bit more here

   <Marc-Alexandre> I'm not speaking on the phone because i've already a
   bad enough time to just follow a face 2 face conversation on the phone
   and english is not my native language, but i'm listening

   Good idea. It can be very tough to follow the back-n-forth in the
   conversations, when you can't see the people - especially when its not
   your first language.

   <Marc-Alexandre> indeed

   <Marc-Alexandre> It would have been easier to be in person

   <alanr> Call for questions/comments to be had by the end of the call...

   <ericP> BillBug: are our identifiers intended to provide persistent
   identifiers for database records?

   <alanr> marc are you there?

   <ericP> Marc-AleXandreNolin: doing well in current direction. need a
   simple set of rules for URIs

   Sorry - I had a question and a statement:

   statement: OK URIs are intended to provide persistent identifiers for
   database records.

   question: Are we convinced the definition of OK URIs will be able to
   accommodate the different requirements between retrieving static
   "documents" and retrieving resources that only ever exist at the other
   end of an algorithmically and dynamically generated URL?

   <ericP> DanielRuben: want NCBO ontologies to be synergistic with what
   we produce

   <Marc-Alexandre> and publish these rules on community managed pages
   like Purl

   What I read in the current document
   tices/Recommendations/DraftTalk#preview) re: public database records
   seems way to loose to provide this guarantee - at least if the desire
   is for long-term stability for these derived URIs.

   <ericP> ... need mapping layer covering entities described by multiple

   <ericP> Sudeshna: keep track of who's using OK URIs in what ontologies
   and datasets

   <Marc-Alexandre> Has an example, the set of rules to write URI's on the
   Bio2RDF system is written there
   [12]http://bio2rdf.org/JSPWiki/Wiki.jsp?page=URISyntax . I don't say
   that should be the set of rules that HLCS adopt, it is just the rules
   we used here.

   <ericP> alanr: jar's doc discusses validating a comittee to establish
   and bless OK URIs

   <ericP> Jeremy: there are cool URIs that are not OK URIs?

   <ericP> alanr: yes. we don't know how to use conneg in OK URIs and Cool
   URIs doc grounded on Tag findings that jar and alanr can't grok

   <alanr> jonathan.rees@gmail.com

   <ericP> Steven: interested in how you get a description of a resource
   given it's identifier

   For resource type, can't we use/extend the DC Types:


   <Marc-Alexandre> isn't rdf:type supposed to be used for the type or I'm
   missing something

   <ericP> Paolo: am particularly interested in version and variance

   <ericP> ... want a common vocabulary for axes of version and variant

   From [14]http://www.w3.org/TR/rdf-schema/#ch_type

   "rdf:type is an instance of rdf:Property that is used to state that a
   resource is an instance of a class.

   A triple of the form:

   R rdf:type C

   states that C is an instance of rdfs:Class and R is an instance of C.

   The rdfs:domain of rdf:type is rdfs:Resource. The rdfs:range of
   rdf:type is rdfs:Class."

   This is too unconstrained for the purpose of type that Jonathan was
   talking about.

   <ericP> ericN: would like some framework for identifying contracts of
   term evolution

   <Marc-Alexandre> ok, I see

Summary of Action Items

   [NEW] ACTION: EricN to see if terms from URI Recommendations Document
   adequately support [a strawman] version and revision ontology, i.e. can
   you express policies [recorded in
   [NEW] ACTION: ericP to determin HCLS charter close [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [17]scribe.perl version 1.128
    ([18]CVS log)
    $Date: 2007/07/17 01:01:43 $


   1. http://www.w3.org/
   2. http://www.w3.org/2007/07/16-BioRDF-irc
   3. http://www.w3.org/2007/07/16-BioRDF-minutes#agenda
   4. http://www.w3.org/2007/07/16-BioRDF-minutes#item01
   5. http://www.w3.org/2007/07/16-BioRDF-minutes#item02
   6. http://www.w3.org/2007/07/16-BioRDF-minutes#ActionSummary
   7. http://biocyc.org/ECOLI/NEW-IMAGE?type=PATHWAY&object=GLYCOLYSIS&detail-level=3
   8. http://www.w3.org/2007/07/16-BioRDF-minutes.html#action01
   9. http://www.w3.org/2007/07/16-BioRDF-minutes.html#action02
  10. http://bio2rdf.org/JSPWiki/Wiki.jsp?page=Bio2RDFURIProposal
  11. http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Recommendations/DraftTalk#preview)
  12. http://bio2rdf.org/JSPWiki/Wiki.jsp?page=URISyntax
  13. http://dublincore.org/documents/dcmi-type-vocabulary/
  14. http://www.w3.org/TR/rdf-schema/#ch_type
  15. http://www.w3.org/2007/07/16-BioRDF-minutes.html#action01
  16. http://www.w3.org/2007/07/16-BioRDF-minutes.html#action02
  17. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  18. http://dev.w3.org/cvsweb/2002/scribe/


office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Tuesday, 17 July 2007 01:05:01 UTC