Re: [Fwd: Re: Serialization skos:Concept vs owl:Thing vs rdf..]

Hi Simon,

  
> Nevertheless, it does somewhat undermine the rationale for SKOS to 
> convert an ontology into OWL terminology when it had been formalized 
> using only RDF and SKOS. 
> SKOS is intended to be a bridge for communities whose requirements do 
> not require OWL.
> I'm currently trying to convince a couple of communities (GeoSciML, GML) 
> that they should replace their bespoke vocabulary encodings with SKOS, 
> since SKOS appears to satisfy almost all the requirements from those 
> communities.
> The target audience comes from an XML/XSD background, so there is an 
> initial challenge in getting over the RDF data-model humps (e.g. the 
> fact that many serializations are fully equivalent).
> This would be easier if the tools did not all-of-a-sudden munge the 
> resource types (even if the munging is correct according to RDF/OWL model).
> But perhaps I've just got to get over that. 


Yes, you just cannot avoid that. Note that you can also try to turn this (very slightly) at your advantage : it really says that what is important in RDF is the abstract graph and what can be derived from the accompanying semantics, not the way it is serialized.

To come back to the initial problem of owl:Thing in the export, note that even in RDFS you could have an inferred triple that says that your concept is of type rdfs:Resource, and have a legitimate serialization rendering that. 
As an improvement, Protégé/OWL could have an option for not exporting triples that are redundant with other triples, from the perspective of RDF and OWL semantics. Or, better, triples which involve classes and properties from a specific namespace. But I don't know if this is on the agenda. 


[...]
> It does matter to some XSLT processing tools that we have developed, but 
> I guess that points to the fact that SPARQL etc is the appropriate 
> interface for processing RDF, not XSLT.


You perfectly got it!

Cheers,

Antoine

>  
> --------------------------------------------------------
> *Simon Cox
> *
> European Commission, Joint Research Centre
> Institute for Environment and Sustainability
> Spatial Data Infrastructures Unit, TP 262
> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
> Tel: +39 0332 78 3652
> Fax: +39 0332 78 6325
> mailto:simon.cox@jrc.ec.europa.eu
> http://ies.jrc.ec.europa.eu/simon-cox
> 
> SDI Unit: http://sdi.jrc.ec.europa.eu/
> IES Institute: http://ies.jrc.ec.europa.eu/
> JRC: http://www.jrc.ec.europa.eu/
> 
> --------------------------------------------------------
> 
>  
> 
> ------------------------------------------------------------------------
> *From:* Simon Jupp [mailto:simon.jupp@manchester.ac.uk]
> *Sent:* Wednesday, 16 September 2009 15:24
> *To:* Simon Cox
> *Cc:* steve.richard@azgs.az.gov; 'Guillame Duclaux'; public-esw-thes@w3.org
> *Subject:* Re: [Fwd: Re: Serialization skos:Concept vs owl:Thing vs rdf..]
> 
> 
> Protege and the SKOSEd plugin don't "promote" SKOS to OWL. The 
> SKOS concepts and relationships are defined as an OWL vocabulary. When you
> load SKOS files into Protege you simply get a representation of what was 
> asserted (which may include additional triples that are inferred, such 
> as those asserting rdf:type owl:Thing).
> 
> Any SKOS exported from Protege as RDF/XML is likely to contain 
> these triples that use the OWL vocabulary, but why should this matter to any
> tool that consumes RDF? Any constructs they don't handle should just get 
> ignored. If a service can't handle the RDF (and SKOS) generated by
> Protege then I would be interested to know why, it is after all 
> just RDF, nothing special about it because it has some additional 
> OWL vocabulary in there.
> 
> On the point of consistent serialisation, I can sort of see a case 
> for being consistent, but RDF can be serialised to XML in multiple 
> ways, so I wouldn't expect any tool to rely on particular style. SKOS 
> was designed to be flexible and extensible, this means it's quite hard 
> to define what pure SKOS is, any standalone SKOS editor will have 
> limits on what can be expressed. To provide ultimate flexibility you 
> would need an OWL full or RDF editor, but this is possibly the wrong 
> level of abstraction for most people working with SKOS.
> 
> Cheers
> Simon
> 
> On 15 Sep 2009, at 07:51, Simon Cox wrote:
> 
>> I guess Protege uses OWL as its internal model, so this kind of 
>> behaviour, though annoying, is to be expected.
>>  
>> What this points to is that the world needs a RDF or SKOS editor that 
>> does /not/ gratuitously promote everything up to OWL.
>> Promoting everything to OWL kinda misses the point of having SKOS, 
>> which is explicitly for applications that do not need to go all the 
>> way to OWL.
>>  
>> I'll forward this to the W3C SKOS list, since it is a follow-up to the 
>> discussion we triggered in June.
>>  
>> --------------------------------------------------------
>> *Simon Cox
>> *
>> European Commission, Joint Research Centre
>> Institute for Environment and Sustainability
>> Spatial Data Infrastructures Unit, TP 262
>> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
>> Tel: +39 0332 78 3652
>> Fax: +39 0332 78 6325
>> mailto:simon.cox@jrc.ec.europa.eu
>> http://ies.jrc.ec.europa.eu/simon-cox
>>
>> SDI Unit: http://sdi.jrc.ec.europa.eu/
>> IES Institute: http://ies.jrc.ec.europa.eu/
>> JRC: http://www.jrc.ec.europa.eu/
>> --------------------------------------------------------
>>  
>>
>> ------------------------------------------------------------------------
>> *From:* Stephen M Richard [mailto:steve.richard@azgs.az.gov]
>> *Sent:* Monday, 14 September 2009 19:30
>> *To:* Simon Cox; Guillame Duclaux
>> *Subject:* [Fwd: Re: Serialization skos:Concept vs owl:Thing vs rdf..]
>>
>> Simon, Gilly--
>> I noticed that Protege is randomly encoding as either skos:concept or 
>> owl:thing with rdf:type=&skos;Concept. I posted a question on the 
>> skos-dev list, here's simon's response (full discussion at 
>> http://groups.google.com/group/skos-dev/browse_thread/thread/1b37afd209da564d?hl=en). 
>> Someone posted an xslt to get rid of the owl:things. Basically its a 
>> Protege issue--what I started with is all skos.
>>
>> steve
>>
>>
>>
>> -------- Original Message --------
>> Subject: 	Re: Serialization skos:Concept vs owl:Thing vs rdf..
>> Date: 	Wed, 19 Aug 2009 03:48:45 -0700 (PDT)
>> From: 	Simon Jupp <simon.jupp@gmail.com>
>> Reply-To: 	skos-dev@googlegroups.com
>> To: 	skos-dev <skos-dev@googlegroups.com>
>> References: 
>> <d8e4f408-dc49-49e9-be28-e2c4ad9c11cf@i18g2000pro.googlegroups.com>
>>
>>
>>
>> I don't see why it matters, when you say unclean, do you mean for the
>> human eye? Can you give an example where this might be a problem? It
>> is a little redundant, but it shouldn't be a problem for any tools
>> that consume RDF/XML.
>>
>> Looking at your files I do see that the RDF/XML rendering seems to be
>> a little inconsistent. I will speak to the OWL API developer to find
>> out why this is.
>>
>> Cheers
>> Simon
>>
>> On Aug 19, 2:26 am, smrAZGS <steve.rich...@azgs.az.gov> wrote:
>> > I've noticed the same issue. Converting to OWL doesn't seem like a
>> > solution, since the point of a SKOS encoding is to use elements in
>> > the  SKOS namespace. I recognize that skos:concept and owl:thing with
>> > rdf:type=&skos;Concept are logically equivalent, but isn't is
>> > problematic if you're trying to automate use of the document if the
>> > encoding might use one of two equivalent syntax approaches in the same
>> > document- it just doesn't seem 'clean'. If a document is supposed to
>> > be a SKOS encoding it seems like there should be some way to ensure
>> > that it uses SKOS elements, not owl?
>> >
>> > steve
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups "skos-dev" group.
>> To post to this group, send email to skos-dev@googlegroups.com
>> To unsubscribe from this group, send email to skos-dev+unsubscribe@googlegroups.com
>> For more options, visit this group at http://groups.google.com/group/skos-dev?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
>>
>> -- 
>> Stephen M. Richard
>> Section Chief, Geoinformatics
>> Arizona Geological Survey
>> 416 W. Congress St., #100
>> Tucson, Arizona, 85701 USA
>>
>> Phone: 
>> Office: (520) 209-4127
>> Reception: (520) 770-3500 
>> FAX: (520) 770-3505
>>
>> email: steve.richard@azgs.az.gov
> 
> 
> 
> Simon Jupp
> simon.jupp@manchester.ac.uk <mailto:simon.jupp@manchester.ac.uk>
> http://www.cs.man.ac.uk/~sjupp/
> 
> 
> 
>

Received on Thursday, 17 September 2009 13:19:49 UTC