RE: [SKOS, SPARQL, ALL] Closure and SPARQL

See comments below:

 

> -----Original Message-----
> From: Pat Hayes [mailto:phayes@ihmc.us]
> Sent: maandag 12 december 2005 18:59
> To: Christoffel Dhaen
> Cc: public-swbp-wg@w3.org
> Subject: RE: [SKOS, SPARQL, ALL] Closure and SPARQL
> 
> >Hi all,
> >
> >I realize I should never have mentioned the
> >domain-range, and never should have used
> >"inferred". I understand why Gary, and I imagine
> >a lot of other people, got very confused when I
> >brought this up. This is beyond the scope of the
> >query language since "new" information is
> >"added" to the graph and would require a
> >reasoner or similar mechanism. This was never my
> >intention.
> >
> >All I wanted to point out was transitive
> >closure. And has been noted by E.Franconi: " you
> >need a full fledged "graph" query language,
> >while I guess that SPARQLl suffers of a mixed
> >origin: a bit of SQL/relational data model and a
> >bit of graph data model."
> >
> >Thatıs all. RDF is a graph, it has native transitive properties.
> 
> That phrase does not make sense to me. Can you
> please explain what you mean by 'native
> transitive'?
>
Just the subClass and subProperty. Even though you can create your own transitive properties, these 2 are transitive by nature.
 
> RDF uses a graph *syntax*, but that is merely a
> syntactic convention. Nothing follows from this
> about transitivity or otherwise of the relations
> described by an RDF graph.
> 
I tend to look at the relations in an rdf-file as being edges in a graph.
It's often referred to and visualized as a graph, that's all.
Somehow this makes things easier for me to look as it as a graph instead of triples. 

> >Being able to express in query that only the
> >direct nodes should be taken into account, or
> >that the transitive nature of the properties has
> >to be taken into account is a logical step.
> 
> What is a 'direct node'?

Directly asserted node of the graph.
If A subClassOf B, and B subClassOf C, then A is directly connected to B, and B is directly connected to C. A is indirectly connected to C since there is a path you walk by following the transitive subClassOf edge.

> 
> RDF does not require *any* properties to be
> transitive. RDFS requires rdfs:subClassOf and
> rdfs:subPropertyOf to be transitive, but nothing
> else.  Are you referring to queries that assume
> RDFS completion of the query graph, i.e. that it
> is closed under RDFS entailment?
> 

RDFS entailment is what I had in mind.



> >  No more, no less.
> >The complexity of introducing this: minimal. I
> >only mentioned it because it has some
> >implications, it won't implement itself. I just
> >got the impression that there was a concern that
> >implementing this would be far to complex. It
> >isn't.
> >Hierarchical queries do something similar, and
> >their implementations and syntax vary.
> >And thatıs exactly what I meant by
> >"non-standard": some implementations will add
> >their own keywords to SPARQL to add this
> >feature. Others will opt to define the indirect
> >variant of a transitive property, like
> >ns1:indirectSubclassOf for rdfs:subClassOf, or
> >as has already been suggested,
> >skos:inNarrowerClosure for skos:narrower.
> >Namespaces will vary, keywords will vary,
> >implementations will vary, and interoperability
> >between systems will be lost. It is far from
> >unwarranted.
> >
> >The /*+RULE*/ example was not a great one, but
> >the comparison to hierarchical queries still
> >holds: For a standard database there was already
> >a need to create hierarchical queries. Rdf has a
> >hierarchy in classes and properties because the
> >property is transitive.
> 
> RDF makes no transitivity assumptions at all.
> RDFS makes it for subClass and subProperty. Are
> you talking about RDF or RDFS?

Seems I've been mixing RDF and RDFS since they are defined in terms of each other.  

> 
> Pat Hayes
> 
> 
> --
> ---------------------------------------------------------------------
> 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
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.13.13/197 - Release Date: 9/12/2005
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date: 12/12/2005

Received on Tuesday, 13 December 2005 14:02:40 UTC