Re: Abstract syntax: an attempt

>Brian McBride wrote:
> >
> > Hi Sergey,
> >
> > Sergey Melnik wrote:
> > >
> > > Brian,
> > >
> > > I'd just like to reiterate some of the arguments for making reification
> > > a built-in feature (possibly as an optional layer):
> >
> > I wasn't sure what you meant by 'built in' but I guess you mean 
>specifically
> > called out in the abstract syntax.
> >
> > >
> > > - in M&S, reified statements need to have a URI. It looks like they
> > > should be unique, but nobody wants to deal with uniqueness, but still
> > > some sort of URIs need to be assigned, so we end up having to deal with
> > > different URIs denoting the same statement etc.
> >
> > I have the same question as Danbri here - why do they have to have a URI.
> > M&S allows there construction without.
>
>I'm tempted to postpone arguing about this issue until we worked out
>what anonymous resources are and whether we need them. However, I'd like
>to point out that if you want to use reification in databases, you may
>avoid unintuitive query results if reified statements are unique, i.e.
>have same IDs, whatever they are. To be frank, I only see unnecessary
>complications associated with "multiple occurrences" of reified
>statements, or anonymous resources, but no tangible benefits.

?? Sergey, you seem to relating anonymous nodes with reification in 
some way. To me they seem two distinct and unrelated topics. Can you 
expand on the connection you see between them?

> > > - in M&S, we need a specific vocabulary to express/use reification.
> > > Reification could be defined without relying on vocabularies.
> >
> > I'm wondering what you mean here by 'relying' on vocabularies.  Reification
> > is currently defined using rdf:type, rdf:subject etc.  Those are
> > vocabularies.
>
>I'm joining Graham's suggestion on this issue.
>
> > > - as defined in M&S, reification is extremely verbose and clumsy both in
> > > APIs and in the syntax, and very few people are using it as suggested.
> > > However, I personally believe it is a useful feature when introduced
> > > correctly and compactly, and it can be easily handled in APIs and
> > > databases as an intrinsic model feature.
> >
> > Absolutely.
> > >
> > > Finally, (s1 p1 (s2 p2 o2)) looks nicer in the abstract syntax...
> >
> > Right.  Much neater and simpler.  However ...
> >
> > There has been a bunch of discussion lately on www-rdf-logic about this.
> > It would be very helpful if one someone who understands these issues
> > (far) better than I (Pat, FrankM, ?  please) could summarize the 
>key points -
> > and
> > straighten me out if what I'm about to say is wrong.
>
>I'd love to see this summary, too...
>
> > The upshot of that discussion is that there are (at least) two different
> > concepts floating about, distinguished by the ideas of 'use' and 'mention'.
> >
> > The simplest examples to distinguish these I have seen are:
> >
> >   London is a city.
> >   'London' is a word.
> >
> > The first of these is use, the second is mention of the name 'London'.
>
>I have a feeling that this example might be too simple to illustrate the
>problem, since it could be tackled using urn:cities:London and
>urn:rdf:literal:London.

The point is not that the distinction can't be represented, but that 
it is a real distinction that needs to be respected.

>
> > A logical language needs both mechanisms.  Reification, as described in
> > M&S is an example of mention e.g. Ralph said 'the sky is blue'.
> >
> > My working assumption at the moment is that reification is a different
> > mechanism from nested expressions.  If we use nested expression syntax
> > to represent reification, then a future working group can't use it
> > to represent nested statements.
>
>I tend to agree. My impression is that reification provides a
>qualitatively different instrument, which allows referring to states of
>affairs,

?? Surely referring to states of affairs is what the basic logic 
does. Reification refers to sentences, sentences describe states of 
affairs.

> so the distinguished notation would be justified. I think if we
>need nested expressions (e.g. for representing LISP, rules etc.), we can
>always define some dedicated vocabulary. Ideally, the semantics of such
>a nested expression would be consistent with that defined by RDF "core"
>(i.e. a nested expression in the abstract syntax would be interpreted as
>a nested expression in the domain of discourse),

I dont follow you here. Right now there isnt any nesting in the RDF core.

>with additional
>interpretation functions or relations that would help to capture the
>extra semantics. Again, I'd appreciate a logician's summary on those
>issues...

It would be desirable to have any nested syntax have current RDF as a 
special case, certainly, but seems to be rather awkward to do with 
RDF in its present state. Here's the problem. To represent any kind 
of nesting within the RDF triples framework seems to require treating 
the nested subexpressions as some kind of container. Doing that, 
however, means that the 'nested-syntax' assertion that had the same 
meaning as a simple RDF triple would not be a single RDF triple, but 
something like a triple whose subject and object were containers with 
single elements. One could make artificial definitions to arrange 
that a one-element 'nest container' was equivalent to its only 
member, of course, so it would be *possible* to do it; but not to do 
it naturally. (My proposal to use argument lists rendered using 
triples encoded with 'etc' was an attempt to do this so that the 
binary-relation case turned out to be ordinary RDF triples, but that 
coding technique was broken, as  Sandro explained. In effect, it 
needs quads rather than triples. If the basic RDF item were a quad 
rather than a triple, it would be easy to extend RDF naturally to any 
arbitrarily complicated syntax.)

Pat

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 25 June 2001 10:43:38 UTC