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

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 ...

For reference:
   http://www.w3.org/2001/sw/wiki/Literals_as_Subjects

As Pat once noted, people are free to do whatever they like with RDF 
behind the public interface, even make spaghetti, and the specs don't 
preclude that.

Literal subjects exist in other specs (N3 for example), and are often 
encountered at "run time" when doing rules and inference, and supported 
and documented in various language APIs.

It's not much use to say that a literal will never be in the subject 
position of a triple, as it will, even if just in an abstract form or 
for a moment at runtime. The limitation that it doesn't exist is purely 
at syntax level, as the purpose of RDF is to have generic public media 
types which enable interoperability.

If people have a need to throw data around between systems on the web 
which has literals as subjects, or bnodes as predicates; if there's a 
legitimate demand for it, then I'd guess it would be the job of *a* WG 
to standardize this in order to enable interop at web level.

In RDF, and on the web, URIs are names - I can't see anybody suggesting 
to abandon or avoid using the very thing that makes the web a web, and 
linked data linked..

Best,

Nathan

Received on Tuesday, 31 July 2012 13:27:15 UTC