- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Mon, 16 Jul 2007 21:04:30 -0400
- To: public-semweb-lifesci@w3.org
- Message-ID: <20070717010430.GC3162@w3.org>
http://www.w3.org/2007/07/16-BioRDF-minutes
HCLS IG
16 Jul 2007
See also: [2]IRC log
Attendees
Present
susie, Chimezie_Ogbuji, Don_Doherty, Khalid, BillBug, JonathanR,
AlanR, JeremyZucker, VijayBuluse, StevenDobson, ericP,
ElizabethWu, PaoloCiccarese, Sudeshna, Marc-AleXandreNolin,
DanielRuben, ericN, EricNeuman
Regrets
Chair
SV_MEETING_CHAIR
Scribe
BillBug
Contents
* [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
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:
[7]http://biocyc.org/ECOLI/NEW-IMAGE?type=PATHWAY&object=GLYCOLYSIS&det
ail-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
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
[8]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
[9]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
[10]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
([11]http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Prac
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
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
[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:
[13]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 [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
[15]http://www.w3.org/2007/07/16-BioRDF-minutes.html#action01]
[NEW] ACTION: ericP to determin HCLS charter close [recorded in
[16]http://www.w3.org/2007/07/16-BioRDF-minutes.html#action02]
[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 $
References
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/
--
-eric
office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509
(eric@w3.org)
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