[Tdwg-guid] Jena examples?

Roger Hyam roger at tdwg.org
Tue Sep 26 18:39:15 CEST 2006


I suggest we move the discussion to the TAG list as it is wider than LSIDs.

Please join the TAG list Sally - we would appreciate your thoughts

http://lists.tdwg.org/mailman/listinfo/tdwg-tag

I have set up a wiki page here:

http://wiki.tdwg.org/twiki/bin/view/TAG/EstablishingLsidVocabularies

where I am brain storming the issues. Everyone is invited to add 
ideas/issues to this page.

I would like to just take a series of decisions so that we have a 
solution to these issues as soon as possible but I am aware that we must 
move forward as a group. This is slower but has to be done.

The situation with TCS/RDF isn't as bad as it might seem. Rob Gales 
version is based very heavily on the RDFS version that I did earlier in 
the year for GUID-2 (which IPNI and IF use) so provided Steve keeps his 
version buried we really only have two versions in the wild and they are 
really two ports of the same thing.

If I could have answers to two questions I could probably get the 
TCS/RDF vocabularies set up in the right place pretty damn quickly.
   * How do we divide the namespace? - I suggested an approach earlier.
   * What language do we use for the RDF vocabularies in metadata 
responses? RDFS/OWL

I have run out of time here today so I will not have a chance to add 
anything more to the wiki but will look out the RDFS and OWL versions of 
TCS Names part tomorrow and try and provide a commentary on any differences.

More later,

Roger



Sally Hinchcliffe wrote:
> Hi Steve/all
>
> I agree that we should start trying to nail down the TCS/RDF more 
> firmly. I know that Roger wants to discuss this at TDWG but I think 
> some firm proposals are needed to take to the meeting - and some 
> robust examples as well, for those of us who struggle with RDFS, OWL 
> et al and need to see actual implementations to properly engage with 
> the proposals. Otherwise, as you say, we will end up with some de 
> facto standards based on LSID implementations which were never 
> intended to be anything more than proof of concepts.
>
> Now is a good time to tackle this for us, because we're re-opening 
> the LSID implementation that we did for IPNI and trying to bring it 
> up to something that will be properly releasable and can be more 
> widely publicised. As part of that work it will be easy to make any 
> changes to the metadata that's produced. Once released, pressures of 
> time and other projects will make it hard to re-open the work and 
> change the metadata output.
>
> Is TAG the best place to discuss this? I'm not on that mailing list 
> but I can probably join if the discussion is going to be over there. 
>
> Let me know
>
> Sally
>
>   
>> Hi Sally,
>>
>> No problem.  The task was to create a prototype LSID resolver, not to 
>> solve all the KR issues surrounding taxon concepts.  However, I do think 
>> it's time we start talking about these issues.  I worry that the 
>> prototype resolvers we set up will become de facto reference 
>> implementations, that other people will start to construct services 
>> modeled on the prototypes without us ever having gone back to talk about 
>> what worked and what didn't.
>>
>> I know there are several versions of TCS-in-RDF floating around.  I 
>> think Roger's is an RDFS document.  Rob Gales created an OWL-DL version 
>> for the GBIF demonstration project that Jessie and he worked on this 
>> summer.  Early this year I created a partial implementation in OWL-Lite 
>> (that I've since discarded).  While each one is "TCS", they're all 
>> substantially different in the way they represent TCS classes and 
>> properties, in part because the different representation languages 
>> (RDFS, OWL-Lite, OWL-DL) have different language features and expressive 
>> powers.
>>
>> It would be nice if we could devise one standard RDF implementation of 
>> TCS.  I don't care which one we use, but I would like to narrow the 
>> field to one so we can get the details sorted out.  I'm talking about 
>> details like resolvable namespaces, typed versus non-typed literals, the 
>> use of anonymous resources, and serialization issues like the 
>> references-to-resources problem that cropped up in the IPNI example 
>> Peter Hollas is working from.  These details are quite important because 
>> certain decisions taken here can effect the larger network of linked 
>> data providers. 
>>
>> Take the anonymous resources issues:  If you look at the example Peter 
>> cites, the typifiedBy property refers to an anonymous NomenclaturalType 
>> that has a dc:title.  Within a single data provider, this is no big deal 
>> because many different data objects can refer to this 
>> NomenclaturalType.  However the use of anonymous resources can cause big 
>> problems when you try to harvest and index the data from multiple 
>> providers.  It also causes problems for the caching use case.
>>
>> It would be nice to discuss some of these things, perhaps within TAG.
>>
>> -Steve
>>
>>
>> Sally Hinchcliffe wrote:
>>     
>>> Hi Steve /all
>>>
>>> We took that syntax straight from Roger's RDF/TCS examples. I think 
>>> Roger was going to do more work on tidying up those sorts of loose 
>>> ends. I have to admit that my knowledge of RDF and particularly RDFS 
>>> is pretty superficial
>>>
>>> We can switch to either the shorter format or the safer fully 
>>> qualified URI - what do people think would be better?
>>>
>>> Sally
>>>
>>>
>>>   
>>>       
>>>> By the way, the IPNI example you cite has an error:
>>>>
>>>> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" />
>>>>
>>>> Many RDF/XML parsers will see &tn; as an entity which cannot be 
>>>> resolved.  Since I don't have a copy of the ontology (and 
>>>> http://tdwg.org/2006/03/12/TaxonNames does not resolve), I can only take 
>>>> a guess that it should look something like:
>>>>
>>>> <tn:nomenclaturalCode rdf:resource="tn:botanical" />
>>>>
>>>> However, using XML namespace prefixes in resource references inside 
>>>> RDF/XML documents tends to cause problems because not all RDF/XML 
>>>> parsers are smart enough to dereference the namespace prefix and build a 
>>>> fully-qualified resource URI.  A safer form of the above would be the 
>>>> fully qualified resource URI which looks like:
>>>>
>>>> <tn:nomenclaturalCode rdf:resource="http://tdwg.org/2006/03/12/TaxonNames/botanical" />
>>>>
>>>>
>>>> -Steve
>>>>
>>>>     
>>>>         
>>> *** Sally Hinchcliffe
>>> *** Computer section, Royal Botanic Gardens, Kew
>>> *** tel: +44 (0)20 8332 5708
>>> *** S.Hinchcliffe at rbgkew.org.uk
>>>
>>>   
>>>       
>
> *** Sally Hinchcliffe
> *** Computer section, Royal Botanic Gardens, Kew
> *** tel: +44 (0)20 8332 5708
> *** S.Hinchcliffe at rbgkew.org.uk
>
>
> _______________________________________________
> TDWG-GUID mailing list
> TDWG-GUID at mailman.nhm.ku.edu
> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid
>
>   


-- 

-------------------------------------
 Roger Hyam
 Technical Architect
 Taxonomic Databases Working Group
-------------------------------------
 http://www.tdwg.org
 roger at tdwg.org
 +44 1578 722782
-------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20060926/d9f8343d/attachment-0001.html 


More information about the tdwg-tag mailing list