Re: [foaf-protocols] foaf classes for primary Topic

Peter Williams wrote:
> A good primer on Linq is here
> http://msdn.microsoft.com/en-us/magazine/cc337893.aspx.
>
> For me, a 30 year programmer, that the data queries are integrated into a
> mainstream language (C) is what counts. Its strongly typed (which matters to
> me, a confessed security engineer trained to reason with type systems
> transformations when engineering higher assurnace). 
>   
Peter,

Copied in the LOD mailing list as I think your comments should also be 
digested by this community.
> In RDF terms, linq (in C#) gets me to 80% of the RDF revolution with no
> effort whatsoever - having left behind rectangular sql tables and the limits
> of its referential integrity relations.  
>
> I cannot WAIT for the linq2rdfa driver to appear. It's going to be a killer
> app. Just imagine a million vb programmers doing SPARQL ASK and CONSTRUCTSs
> - and they don’t even know (or care) that they are doing it!
>
> Whereas folks here would speak of data engineering issues in often
> philosophical or abstract terms (the religion of REST, in general), in linq
> the issues were presented to this reader in VERY concrete terms. Process a
> graph: means walk a object tree in memory built dynamically from the
> relations of the ER model. Early load a collection property means the outer
> collection would store references to complex "object" properties, not their
> values (until needed). If the references are not pointers but a restful url
> ref (URIs), then fine. Who cares. A pointer is a pointer. A capability is a
> capability. A key is a key. Certain primitives are necessary; and we cannot
> argue for ever about every monad. The clock is ticking on the semweb.
>
> So, so far, linq has been my bridge to PRACTICISING RDF (and thus foaf docs)
> - beyond issuing a sparql query based on substituting some parameter into a
> stored string that canned up all my design logic (when searching out the
> foaf+ssl pubkeys per webid).
>
> Yes, linq has limited supported for relation types (more or less classical,
> reversible 1:n relations). But, C# comes with a type extension capability.
> Even in the .NET semweb toolkit, _runtime_ type extensions add to the query
> operator set classical functional programming operators, such as Map. The
> obviously math-centric programmer uses it extensively, when processing the
> RDF ontology metadata into .Net metadata. 
>
> This all taught me to think mathematically (again), and be bold: define
> languages to express your designs peter, don’t simply use languages to
> implement. Restructure data, Peter, for the kind of processing you need to
> do. Unlike XLST and reading RDF ontologies, none of this linq stuff is
> presented in an "esoteric" manner. Folks from the bottom half of the class
> (i.e. me) can get it. The top half are busy defining their own advanced Map
> operators...of course. Great! I'm eager use them.
>
> Now, as you noted, Kingsley already adopted that tool chain. And, Ill guess
> he dominates it (unlike me). That was a few years ago, and Im eager to hear
> what he thinks of it ... now.
>
> Side note: Ive only used the "rdfmetal" code generator command line tool,
> from the linq2rdf source. I have not used the graphical designer tool that
> code generates, as that would me too tightly bound to micosoft's tool chain.
> Ive learned to avoid that elixir (since Microsoft's tools group rewrites its
> design tooling every 3 years, turning elixir into poison).
>
> Since the implementation of the semweb toolkit makes extensive use of .NET
> generics and functional extensions - producing a semweb library not
> dissimilar in scope to Jena - so far it has provided an excellent teaching
> of linq. It hasn’t advanced my RDF knowhow much, though! Im still stuck in
> library science land when working with RDF natively (and I never studied
> library science, only computer science).
>
> At the same time, I recognize that sparql queries (and protocol) are doing
> fine for me. (They are a better version of what we use extensively in the
> backrooms of the realty business -  a 10 year old http-based querying
> protocol called RETS, a query language called DMQL, all of which has an
> object-centric data model with metadata). 
>
> To promote Semweb "native" (and FOAF in particular), we just need to design
> and promote a library of ADVANCED sparql queries that SHOWCASE the ”more
> interesting" foaf relations. Going BEYOND selecting, just as discussed here
> in the ASK and CONSTRUCT cases used in authorization processing, we need to
> be teaching the bottom half of the class the GRAPH aspects of RDF and
> SPARQL. If I measure myself (which is good for 51% of people), its poorly
> understood/leveraged (folks are stopping learning having learned to binding
> values to variables, via select, like your do in your predicate calculus 101
> course, in a first year university engineering course). 
>
> Studying and promoting the Authorization logic (which leverages ASK, etc )
> may be EXACTLY the thing to do. Through application, we all get to study the
> finer features of RDF and SPARQL, through a problem lots of folks
> intuitively understand (authorization). There are a million applications of
> authorization; one per business domain. So, there should be lots of takeup.
>
> Do this, and in the bottom half of the classes (political pun) won't give up
> the struggle, halting progress at 80% revolution point that linq gives us.
> Of course, Microsoft can extend linq for all the more advanced relations
> whenever it wants. Its pretty clear that this C# v3 cut is just a stepping
> stone - hopefully on the road to the semweb. C# v4 is a coming...
>
> Let's build that linq2rdfa driver! It’s the killer app for the semweb, in
> Microsoft land.
>   
Only comment: linq2rdf driver with support for HTML+RDFa data 
representation :-)

Kingsley
>
>
>
> -----Original Message-----
> From: foaf-protocols-bounces@lists.foaf-project.org
> [mailto:foaf-protocols-bounces@lists.foaf-project.org] On Behalf Of Dan
> Brickley
> Sent: Saturday, January 30, 2010 3:47 PM
> To: Peter Williams
> Cc: foaf-protocols@lists.foaf-project.org
> Subject: Re: [foaf-protocols] foaf classes for primary Topic
>
> On Sat, Jan 30, 2010 at 10:28 PM, Peter Williams
> <pwilliams@rapattoni.com> wrote:
>   
>> I’m running into horrendous (for me) hurdles, when generating code from
>>     
> the
>   
>> foaf ontology. The code generator only looks at certain properties and
>> relations, and  ALL those that are specified.
>>     
>
> Let's try to get to the bottom of this!
>
> You're working on Windows, in C#, right? Do you have a pointer to the
> tools you're using? Anything I can try?
>
> As it happens, I've recently started dabbling in C# again recently
> (for XMPP / remote control stuff, not RDF yet)...
>
>   
>> The underlying issue behind this is not FOAF’s design  but the code
>> generator and me. (Remember I’m almost incompetent practitioner, when it
>> comes to knowledge systems  and data query designs)
>>     
>
> Well it's a daunting pile of technology to integrate. This has always
> been one of my concerns around FOAF security work; it is hard to be
> fully fluent in all the required and sometimes messy technologies...
>
>   
>> Take
>>
>>
>>
>>   <rdf:Property rdf:about="http://xmlns.com/foaf/0.1/primaryTopic"
>>
>>  vs:term_status="testing" rdfs:label="primary topic" rdfs:comment="The
>> primary topic of some page or document.">
>>
>>     <rdf:type
>> rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
>>
>>     <rdf:type
>>     
> rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
>   
>>     <rdfs:domain rdf:resource="http://xmlns.com/foaf/0.1/Document"/>
>>
>>     <rdfs:range rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>
>>
>>     <owl:inverseOf
>> rdf:resource="http://xmlns.com/foaf/0.1/isPrimaryTopicOf"/>
>>
>>     <rdfs:isDefinedBy rdf:resource="http://xmlns.com/foaf/0.1/"/>
>>
>>   </rdf:Property>
>>
>>
>> Unlike other simpler properties of a Person, the domain for primaryTopic
>>     
> is
>   
>> not Person (but Document). The  generated Person .Net class expresses no
>> primaryTopic property for instances. This my (linq/lambda) queries cannot
>> range over it, do early loading for it, etc etc.
>>     
>
> I've always been a bit skeptical about code generation from RDF,
> because the RDF model doesn't care so much about the direction of
> property naming. We could have 'maker' be a property of Document,
> pointing to a Person; or 'made' be a property of a Document, with
> Persons as values. Most RDF tools (eg. databases, syntaxes, SPARQL)
> don't make a big deal about the difference. However code generators
> often do.
>
>   
>> Because Document does not declare a property called primary topic, the
>> Document class generated for .NET similarly omits any concrete property.
>>     
>
> Interesting that this generator doesn't do anything with the triple
>
> foaf:primaryTopic rdf:domain foaf:Document .
>
>   
>> Left to inference, one CAN of course follow the reasoning about documents,
>> foaf Persons, and primaryTopic properties from the domain relations and
>>     
> the
>   
>> subclassing of Person from Document. But this is me, a (relatively)
>> intelligent human, doing the reasoning;  not the code generator.
>>
>>
>>
>> Am I perhaps JUST USING THE WRONG TOOLS, and thus running up against an
>> inherent  brick wall (which is what It feels like). Advice sought.
>>     
>
> I think you might be right. Would direct access to the graph via
> SPARQL be a possible replacement for the code generator?
>
>   
>> Should I just stick to Sparql queries, rather than trying to cast foaf
>> instances into a form that one can then do linq queries on?
>>     
>
> I don't know Linq. I'll try to take a look. Is it actively maintained?
> Maybe the developers would appreciate this feedback too?
>
>   
>> (the .NET linq2rdf toolkit nicely uses generics and metadata – auto
>> translating linq expressions into SPARQL for me… But, I cannot do further
>> local processing of the graph resultset … if I cannot even represent the
>> graph resulting from the quer in the .NET classes).
>>     
>
> http://groups.google.com/group/linqtordf-discuss/topics doesn't look
> too healthy but a 2008 release isn't ancient history, at least -
> http://aabs.wordpress.com/2008/08/01/announcing-linqtordf-v08/
>
> It seems from reading a little that OpenLink have offered some support
> for Linq in the past; perhaps Kingsley might comment?
>
>   
>> Hope this is making sense. Im WAY out of my depth … but the learning is
>>     
> fun
>   
>> J
>>     
>
> Glad you're having fun! Expect similar mails from me w.r.t.
> certificates and tooling in the not too distant future ;)
>
> cheers,
>
> Dan
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter: kidehen

Received on Monday, 1 February 2010 11:52:16 UTC