See also: IRC log
<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!
<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 discourse?
<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 link
<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: http://biocyc.org/ECOLI/NEW-IMAGE?type=PATHWAY&object=GLYCOLYSIS&detail-level=3
<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
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 http://www.w3.org/2007/07/16-BioRDF-minutes.html#action01]
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 http://www.w3.org/2007/07/16-BioRDF-minutes.html#action02]
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 Conference
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 http://bio2rdf.org/JSPWiki/Wiki.jsp?page=Bio2RDFURIProposal
<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 (http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/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 ontologies
<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 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:
http://dublincore.org/documents/dcmi-type-vocabulary/
<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 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