Re: Graphs, some quick comments

Andy Seaborne wrote:
> On 21/04/11 23:50, Nathan wrote:
>> Andy,
>>
>> That's an excellent response, and I fully agree with what you say.
>>
>> However, just where is that used behind the interface model of RDF
>> defined? Who's job is it to define it, and bringing this right back to a
>> personal inter-group level, should the RDF API we're working on, which
>> is for implementation behind the interface, and working with RDF data
>> (whether that be simple usage, or querying, or reasoning and inference)
>> have the same constraints?
> 
> Not ours.  Not W3C even, or anyone?

Indeed, who knows, but thanks for confirming that it's not ours (which I 
take to mean this WG) and not W3C's. I appreciate the clarification.

> The freedom to innovate behind the interface model of RDF matters.

I fully agree, so I can't see any reason for the definition of re-usable 
modular interfaces for use when working with RDF data to be arbitrarily 
constrained in such a way as to preclude this innovation :) Just my 
opinion though, and a rough notion that if the interfaces were 
constrained like that then libraries like Jena and Tabulator would need 
to either break conformance of have two APIs and implementations of 
everything.

> As for the RDF API, I think it needs to help people work with and 
> exchange RDF. Help webapp developers work exchange RDF.

That would be brilliant! All we need is a clear story for following ones 
nose around the web, perhaps definition of how to do read write web of 
data, and a chunk of sparql interfaces for that. We could also constrain 
the interface for say Triple to match that of RDF too and require people 
who want to build sparql implementations, reasoners, rule engines or 
anything n3 compatible to jump through a whole load of additional hoops 
too, very helpful.

> If it is actually an API for RDF+some more, then it is not an "RDF API". 
>  A different name would be more appropriate.

Quite possibly agree, any suggestions on a name? Perhaps, "Generalized 
Interfaces for Working with Triple/Graph-Based Data and often RDF"?

>> And for that last question, if not, to what does it reference? Where is
>> the generalized model?
>>
>>  From everything I can tell, the restrictions are syntactic, even if
>> that's an abstract syntax, and to quote the last RDF WG:
>  >
>> noted that it is aware of no reason why literals should not be
>> subjects and a future WG with a less restrictive charter may extend
>> the syntaxes to allow literals as the subjects of statements.
>>
>> So just where is, or should be, this un-syntax-restricted model (which
>> many of us have came across or needed features of) be defined, if 
>> anywhere?
> 
> Each of the extensions has positives and negatives.  It's not just about 
> technical capability.
> 
> There is counter argument for literals-as-subjects: it leads to apps 
> saying:
> 
> "London" :population 352395 . # London, Ontario :-)

I guess it could lead to apps (or people) trying to saying that, but 
then they can't actually say that on the web using RDF so it wouldn't be 
possible, and thus have no effect. Of course they can say that some 
URI-reference is sameas the literal and say it anyways, or stick it in 
N3, but that's beside the point.

> Since you bring up the RDF API, where you propose graph literals 
> ("triple sets") aren't we getting into a weird situation where RDF-WG 
> has out-of-scope items, sorts out named g-boxes and RDF datasets, and 
> the RDF Web Apps WG does something different with literals-as-subjects 
> (and no semantics)?

Yes, we certainly are! Unsure about the "no semantics" bit though, do 
the semantics not handle literal subjects?

> Will it provide RDF datasets?

It may well do, if they become part of RDF, one thing is for sure, 
whether it does provide them or not, it most certainly won't preclude 
them, and will do whatever possible to ensure that the interfaces in the 
API are compatible and usable by libraries which implement RDF datasets, 
or SPARQL even, even if that means getting rid of TripleSets ("graph 
literals") since SPARQL doesn't handle them.

>> And I guess my point is, it does exists, it's just not written down, and
>> it is different to the constrained syntactic RDF that's defined for use
>> over the wire.
> 
> Is there just one such thing? What is OWL in this world view?

Probably the superset of the triple-type model of all common sem web 
specs I'd have thought.

Best,

Nathan

>> Andy Seaborne wrote:
>>> Nathan,
>>>
>>> Another way to look at it is that the key is exchange over the web.
>>> RDF is defined for exchange needs.
>>>
>>> What happens within each site with that data isn't the focus of RDF
>>> providing they meet the specs at the boundaries and the RDF semantics
>>> define what conclusions can be drawn from the exchanged data. There
>>> can be many different per-site processing models; what RDF provides is
>>> a way to communicate over and above bytes and syntax.
>>>
>>> Andy
>>>
>>> On 21/04/11 20:57, Peter Frederick Patel-Schneider wrote:
>>>> I don't think that this is correct.
>>>>
>>>> In my opinion RDF and RDFS is defined/constrained by its semantics, or
>>>> at least it should be! In the RDF Semantics you find the bulk of the
>>>> technical details, and in RDF Concepts you find definitions of many of
>>>> the basic concepts of RDF, mostly in Section 6.
>>>>
>>>> Yes, RDF/XML, the only official exchange syntax for RDF, is not a
>>>> complete syntax for RDF graphs, but that is really a minor point.
>>>>
>>>> The stuff you mention below is not (yet?) a part of RDF.
>>>>
>>>> peter
>>>>
>>>>
>>>> From: Nathan<nathan@webr3.org>
>>>> Subject: Graphs, some quick comments
>>>> Date: Thu, 21 Apr 2011 10:52:52 -0500
>>>>
>>>>> (just dropped these in #swig, copying here)
>>>>>
>>>>> RDF is defined/constrained by it's serializations currently, so
>>>>> anything
>>>>> in the model/abstract is in the serializations, so when we discuss
>>>>> things like multiple graphs, graph literals, named graphs, it's 
>>>>> done in
>>>>> terms of syntax, when really there is hardly ever a case where you 
>>>>> need
>>>>> multiple graphs in the syntax, other than when dumping stores or
>>>>> sets of
>>>>> data, and that ain't RDF.
>>>>>
>>>>> however, behind the interface you need this stuff all the time, but 
>>>>> not
>>>>> over the wire, and RDF doesn't handle that.
>>>>>
>>>>> so, perhaps a higher problem is: RDF is defined in terms of on the 
>>>>> wire
>>>>> needs, but RDF is used as a data model for working with data behind 
>>>>> the
>>>>> interface, and the two have different requirements.
>>>>>
>>>>> if you look at the RDF Graph usecases on the wiki, you'll notice that
>>>>> most of them are about managing or working with data, and people are
>>>>> using the syntax of trig or quads to say what they mean - but only the
>>>>> dumping stores cases actually /require/ having anything in the
>>>>> serialization.
>>>>>
>>>>> Best,
>>>>>
>>>>> Nathan
>>>>>
>>>>
>>>
>>>
>>>
>>
> 
>

Received on Friday, 22 April 2011 17:41:09 UTC