Re: Advancing translational research with the Semantic Web

On May 17, 2007, at 8:43 AM, Pat Hayes wrote:

>> On 17 May 2007, at 05:13, Chris Mungall wrote:
>> [snip]
>>> I've never understood why RDF-reification is so loathed. So the  
>>> syntax is ugly - but I think there may be other reasons RDF/XML  
>>> hasn't won any beauty contests.
>>
>> They are fairly ugly at the model level as well. And there are  
>> problems with nesting, see:
>> 	http://cs-www.cs.yale.edu/homes/ddj/papers/ISWC02.pdf
>
> That paper is about a much extended notion of 'reification' which  
> goes well beyond what this thread is about. Those issues do not  
> arise in RDF reification of RDF itself. (And AFAIKS, this paper  
> doesnt mention any problems with nesting. Are you sure you gave the  
> right reference, Bijan?)
>
>> RDF reification was sort of intended to handle both syntactic and  
>> semantic extension (i.e., quoting), but never specified which
>
> Well, no. The RDF semantics does specify which, and gives an exact  
> semantics, but doesn't say it is normative. That was perhaps a  
> mistake, but it was political rather than technical. BTW, with that  
> published semantics, reification is not quoting. The subject and  
> object of the reified description are the same as the subject and  
> object of the triple being reified, so that RDF reification is 'de  
> re' rather than 'de dicto'. TimBL thought we had made the wrong  
> decision there, and excorciated us (me?) for it.
>
>>  and didn't really consider lots of situations. (For example, it's  
>> not a syntactic error to be missing a predicate triple in a  
>> reification....what does this mean?
>
> Its not a syntactic error to be missing ANY triple in any part of  
> RDF. This was a basic design decision about the whole language. It  
> means simply that some information is missing, i.e. that the  
> description is incomplete.
>
>> Some systems, I believe, treat the presence of a reified triple as  
>> implying the asserted triple,
>
> This interpretation is however explicitly denied by the RDF  
> semantics document.
>
>> but not everyone. RDF/XML has special syntax for asserted 
>> +reifiction, but not reification alone.)
>>
>>> The lack of semantics seem fine to me (although more could be  
>>> done to clear up some misunderstandings in the documentation
>
> Chris, can you say what misunderstandings in the documentation need  
> further work? I would be quite willing to expand on any points that  
> you feel need clarification.

Actually, I thought the document was clear enough, and I assumed the  
exact same interpretation you have outlined above and below. But I  
have heard on various lists (don't recall specifics, sorry) that the  
semantics were unclear, which lead me to question whether my  
interpretation was correct.

>
>>> ) - all I want is a way to attach provenance to a statement.
>>
>> This lack of semantics is the main issue, IMHO.
>
> IMHO not. The semantics is given in the published document, and in  
> any case is kind of easy. There are four possible options based on  
> two decisions (reification implies assertion, or not; subject and  
> object of the reification denote the subject and object URIrefs, or  
> are the subject and object URIrefs.) In both cases, the published  
> RDF semantics takes the second option.
>
> The main issue (for reification and named graphs and everything  
> else in this metadata-of-RDF game) is that there is no sensible  
> general way to give a name, i.e. assign a URIref, to a subgraph of  
> an RDF graph corresponding to a document. One can be constructively  
> ambiguous about the URI of an RDF document denoting the RDF graph,  
> but that doesn't help with the micro-level.
>
>>> The only support I'd want would be some behind-the-scenes  
>>> optimising away of the fact I have 4n triples when a single 3-ary  
>>> predicate would do (but hey, again, as it's RDF anyway, I need at  
>>> least 4 triples for each type-level statement).
>>
>> Jena, to my recent surprise, does this. You can even get some  
>> syntax joy by using an id on the property element so long as you  
>> are ok with the triple *also* being asserted.
>
> Presumably it could be asserted in a different graph, however. I  
> don't think that the assertion issue is a big one for metadata  
> applications like this, as one is presumably (?) only wanting to  
> put metadata onto triples that are in some extant graph out there,  
> i.e. that have been asserted somewhere.
>
> (BTW, this whole discussion is predicated on the (IMO naive)  
> presumption that publication is tantamount to assertion. Part of  
> the motivation for the named graph proposal was to remove this  
> presumption and make assertion (and other possible propositional  
> attitudes) explicit, so that one graph could deny another or cast  
> doubt upon it or agree with it, etc.. Then mere publication is not  
> assertion, and this issue goes away.)

In most translations to RDF/OWL we tend to make the naive  
overstatement and assume publication (in the sense of web publication  
of the triples, not the original scientific publication of course) is  
assertion. I'm not sure how NGs are more expressive than reification  
when it comes to doubt/agreement?

>>> Though support in other syntaxes like SPARQL would be nice, and  
>>> presumably easy to layer on, perhaps in some intermediate  
>>> representation.
>>
>> I think it would be a good and wise thing at this juncture to step  
>> back and consider viable alternatives that are well designed for  
>> one' problem space. I think it's still possible to make a switch,  
>> but every project that falls back on reification because it's  
>> "standard" enshrines it a bit more.
>
> Well, we agree there. I think reification is clunky. What RDF needs  
> is a general way of referring to pieces of its own syntax. The rest  
> is then easy, and there can be many flowers blooming. Its not  
> enough to be able to describe the syntax: you also need to be able  
> to associate an identifier with a piece of extant syntax.  
> Reification does the former, but not the latter.

But there is nothing to stop people assigning URIs instead of using  
bNodes is there?

Chris

> Pat
>
>>
>> Cheers,
>> Bijan.
>
>
> -- 
> ---------------------------------------------------------------------
> IHMC		(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32502			(850)291 0667    cell
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>

Received on Friday, 18 May 2007 22:07:27 UTC