Re: in...of syntax Re: Turtle Last Call: Request for Review

On 2012-07-31, at 13:58, Jan Wielemaker wrote:

> On 07/31/2012 02:42 PM, Steve Harris wrote:
>> On 2012-07-31, at 13:28, Nathan wrote:
>> 
>>> Steve Harris wrote:
>>>> On 2012-07-31, at 02:36, Sandro Hawke wrote:
>>>>> On 07/30/2012 06:37 PM, Andy Seaborne wrote:
>>>>>>> BUt surely IF this is a good idea and worth having, which
>>>>>>> Im assuming it is, then the longer we wait, the more
>>>>>>> problems there will be with deployed systems out there
>>>>>>> which don't support it. Kicking the can down the road is
>>>>>>> not a good way to handle problems of legacy inertia.
>>>>>>> 
>>>>>> Your argument would apply to literals-as-subjects as well;
>>>>>> it's largely a syntax restriction.  If that's going to
>>>>>> happen, it isn't in this WG (by charter), so why not make the
>>>>>> changes in one step, not in multiple steps?
>>>>> If literals-as-subject were primarily a matter of syntax, or
>>>>> were seen as inevitable, I don't think they'd have been ruled
>>>>> out by the charter.    I understand the reasons were mostly
>>>>> about data structures and implementation techniques, but I
>>>>> wasn't paying close attention to the technical content, so
>>>>> perhaps I misunderstood.
>>>> I think that the reason users don't try it is because of the
>>>> syntax restriction, the reason engines don't (on the whole)
>>>> support it is more due to the legacy of getting on for 15 years
>>>> worth of software, research and publications. Knowing the that
>>>> subject can only be a URI or bNode is a useful optimisation for
>>>> many SPARQL engines.
>>> 
>>> wild idea and probably way off course - but what if there was some
>>> kind of "EXTENDED MODE" keyword for sparql queries that let the
>>> engine know to expect literals as subjects and other such things -
>>> would an approach like that allow the engines to keep their
>>> optimizations most of the time, and skip them when demanded?
>> 
>> It would have to be at DB creation time (at least in 4/5store) as the
>> optimisation goes right down into the storage engine.
> 
> I think that the more fundamental question is at the level of modelling.
> My fear would be that we get triples that use proper names of entities
> as subject instead of inventing a URI for this particular appearance of
> the string.  If this happens we introduce massive ambiguity (or conflicts, depending on your viewpoint).  Next is
> 
> "Beer" "sub type of" "Animal".
> 
> URI's have a role: they avoid ambiguity and they can be used to fetch
> data as Open Linked Data.  They are not without problems, but they do
> fix some problems associated with natural language words.
> 
> In any case, the order must be to make a decision at the datamodel first
> and next at the syntax level.  Please don't …

That's a very good point.

People coming from a relational database background will definitely use integer "keys", until they (hopefully) realise why that's a bad idea on the web. e.g.

9876435 a :Product ;
        :name "5cm Trunion (Foo Inc.)" ;
        :cost 12.99 ;
…

To a Linked Data person that's very clearly a bad idea, but it's an obvious, and rational translation from a database table.

- Steve

-- 
Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ

Received on Tuesday, 31 July 2012 13:23:29 UTC