Re: RDF and the Test of Independent Invention

On Apr 29, 2016, at 10:16 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> On 28 April 2016 at 03:13, Pat Hayes <phayes@ihmc.us> wrote:
> 
> On Apr 27, 2016, at 3:49 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>> The test of independent invention [1] asks "If someone else had already invented your system, would theirs work with yours?"
>> 
>> Now imagine if someone had invented RDF (lets call it RDF-L) but with one slight difference.  You are allowed to have literals in the predicate position.
> 
> FWIW, the RDF semantics can handle this without significant change. 
> 
> Ah ha, thanks!
> 
> Well, I suppose that answers the question.  RDF "v.next" passes the TOII (at least this one).
>  
> 
>> Is there a way that RDF could be made to work with RDF-L.  
> 
> Define "work with". RDF is valid RDF-L, and the RDF semantics generalizes to RDF-L without significant change, so the only hard problem is going to be getting RDF-L syntax through an RDF parser. That would require some rewriting of code, to be sure, or inventing a convention (and persuading everyone to adopt it) which disguises predicate-position literals as IRIs. The only really hard part of this is getting everyone to agree on such a convention. 
> 
> OK, so perhaps in future, this problem will be solved, if people move to accepting predicates as literals.  But maybe that wont happen too.  I am unsure here.

I must admit I can't see any plausible use case for this, unlike some other generalizations of RDF syntax (literals in subject position, blank nodes in predicate position) which do have real uses. 

>> This is more than a theoretical question, it has practical implications.  The "triple" model which ties key value pairs to a subject, could be thought of as a type of Entity Attribute Value (EAV) [2] model.  There are many examples of EAV models that allow literals in the "second" position.  JSON springs to mind.
>> 
>> Does RDF pass the TOII?  If not, can we work out a way to make it do so.  After some thought my current favourite idea is to make the following two equivalent:
>> 
>>     "predicate" <--> urn:literal:predicate
> 
> Not sure I like the *equivalence* as it seems to require all existing RDF to be rewritten using URNs, which I would ask God to forbid except it isn't going to happen so there is no need for prayer. But perhaps you don't mean this.  
> 
> Yes, well equivalence may be the wrong term here.  What I would be thinking about is some kind of stop gap to use in the short to medium term.

I think I might have misunderstood your idea, apologies. I thought you meant replace existing URI property names with URNs.

> One thing occurred to me.  Perhaps urn:string is more appropriate than urn:literal.

Well, it is a bit more complicated because of literal datatyping. You need a way to encode both the literal string and the datatype into one URI. RDF and SPARQL engines need to be able to access datatypes of literals to respond to queries and check consistency.  "Plain" (old terminology) literals have datatype xsd:string in current RDF 1.1.

> 
> As you say inventing a convention would help with interoperability.  So is this mailing list a good place to start?
> 
> If urn:string isnt the optimal name, what else could we use?  A new URI called string:
> 
> Or simply just make http URIs for each use case and have the free for all that we have today?

If you can dream up a way to avoid a free-for-all, that would be great. Its essentially a social/political problem rather than a technical one. I have given up on those, myself :-)

Pat

>  
> 
> Pat
> 
>> 
>> Thoughts?
>> 
>> [1] https://www.w3.org/DesignIssues/Principles.html
>> [2] https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 home
> 40 South Alcaniz St.            (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile (preferred)
> phayes@ihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes