Re: More clearly warn that "generalized RDF" is non-standard

Hi Andy,


On Aug 2, 2013, at 12:42, Andy Seaborne <andy@apache.org> wrote:

> (why is this discussed on "comments"?)

It shouldn't have been.  My fault.


> 
> JSON-LD does not allowed the full range of "generalized RDF".


Does any existing spec or implementation?

Regards,
Dave
--
http://about.me/david_wood


> 
> 	Andy
> 
> On 02/08/13 16:22, David Wood wrote:
>> Yes, I concur with Sandro.  The RDF WG inserted the "generalized RDF"
>> description for a good reason.  It is there to allow for alignment
>> with JSON-LD and any future implementations or formats that cannot,
>> for good technical reasons, limit their possible parsings to standard
>> RDF.
>> 
>> That does not mean, however, that we should encourage "generalized
>> RDF" at any point.  Its use should be strongly discouraged in
>> implementations and where that is impossible, as with JSON-LD, then
>> its /social/ use should be strongly discouraged, as with JSON-LD.
>> Hence, I think we should put in the stronger wording but leave the
>> concept in place.
>> 
>> Chair and editor hats simultaneously "on" and "off".  Take that,
>> Erwin Schrödinger!
>> 
>> Regards, Dave -- http://about.me/david_wood
>> 
>> 
>> 
>> On Aug 2, 2013, at 09:15, Sandro Hawke <sandro@w3.org> wrote:
>> 
>>> Speaking just for myself, I think this is going too far.   I think
>>> it does a service to the community to define the term "generalized
>>> RDF" in RDF concepts, since (1) it's used in at least two of our
>>> specs which we'd rather not have depend on each other (JSON-LD and
>>> RDF Semantics), and (2) it's something people come up with on their
>>> own anyway, and this way we tag the discussions about it.  It's
>>> hard to evolve or extend a standard  interchange format, but the
>>> best hope for doing so is to have everyone who wants to add some
>>> feature add it in the same way and talk about it the same way.   By
>>> defining "generalized RDF" in RDF Concepts, I think we're doing
>>> that.
>>> 
>>> All that said, I think it would be a good idea to add something
>>> like the warning note you propose, and perhaps some of the
>>> explanation I just provided.   That is, roughly: Generalized RDF is
>>> not standard RDF, but it can be useful and is reasonable to use
>>> among systems which have all agreed to use it.  If you try to send
>>> it to systems which have not agreed to use it, it won't work.
>>> 
>>> -- Sandro
>>> 
>>> On 08/01/2013 04:17 PM, David Booth wrote:
>>>> I've been thinking further about this, and I have another more
>>>> radical suggestion.
>>>> 
>>>> It seems to me that including even an informative definition of
>>>> "generalized RDF" in the RDF spec substantially increases the
>>>> risk that someone may mistakenly believe that "generalized RDF"
>>>> is some form of standard RDF, when it is not. It is an extension
>>>> of RDF that does not conform to the RDF standard. Hence it is all
>>>> the more important to visibly warn readers about the use of
>>>> generalized RDF.
>>>> 
>>>> Actually, the more I think about it the more I am convinced that
>>>> the inclusion of the definition of "generalized RDF" in the RDF
>>>> spec **at all** is a big mistake, because it substantially
>>>> increases the risk that someone may mistakenly believe that
>>>> "generalized RDF" is some form of standard RDF, when it is not.
>>>> 
>>>> Thus, my second suggestion is to entirely remove the definitions
>>>> of generalized RDF triple, graph and dataset from the RDF
>>>> Concepts document
>>>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-generalized-rdf
>>>> 
>>>> 
>>>> 
> If the RDF Semantics document needs to define the notion of generalized RDF to simplify the semantic rules, then I guess a definition could be included in that document, *with* a big fat warning saying that this definition is included only to simplify the specification of the formal semantics, and does not constitute a part of the RDF standard.
>>>> 
>>>> David
>>>> 
>>>> 
>>>> On 08/01/2013 11:20 AM, David Wood wrote:
>>>>> Hi David,
>>>>> 
>>>>> I acknowledge your comment and your concern.  I *personally*
>>>>> agree with you that we need to carefully word this section of
>>>>> RDF Concepts.
>>>>> 
>>>>> The next RDF WG meeting that I will be able to attend is 21
>>>>> August, so I will put this on the agenda for that meeting.
>>>>> 
>>>>> Regards, Dave -- http://about.me/david_wood
>>>>> 
>>>>> 
>>>>> 
>>>>> On Aug 1, 2013, at 10:28, David Booth <david@dbooth.org>
>>>>> wrote:
>>>>> 
>>>>>> Section 7 defines the notion of "generalized RDF", triples
>>>>>> and datasets, but does not adequately warn that "generalized
>>>>>> RDF" is non-standard. Case in point: this has already led to
>>>>>> some discussion in the JSON-LD group about whether
>>>>>> "generalized RDF" is a form of standard RDF.
>>>>>> 
>>>>>> I suggest rewording section 7 to the following, using a
>>>>>> "NOTE" call-out: [[ <p>It is sometimes convenient to loosen
>>>>>> the requirements on <a>RDF triple</a>s.  For example, the
>>>>>> completeness of the RDFS entailment rules is easier to show
>>>>>> with a generalization of RDF triples.   </p>
>>>>>> 
>>>>>> <p>A <dfn>generalized RDF triple</dfn> is an RDF triple
>>>>>> generalized so that subjects, predicates, and objects are all
>>>>>> allowed to be IRIs, blank nodes, or literals. A
>>>>>> <dfn>generalized RDF graph</dfn> is an RDF graph of
>>>>>> generalized RDF triples, i.e., a set of generalized RDF
>>>>>> triples.  A <dfn>generalized RDF dataset</dfn> is an RDF
>>>>>> dataset of generalized RDF graphs where graph labels can be
>>>>>> IRIs, blank nodes, or literals.</p>
>>>>>> 
>>>>>> <p class="note" id="note-generalized-rdf"> Any users of
>>>>>> generalized RDF triples, graphs or datasets need to be aware
>>>>>> that these notions are non-standard extensions of RDF and
>>>>>> their use may cause interoperability problems. There is no
>>>>>> requirement on the part of any RDF tool to accept, process,
>>>>>> or produce anything beyond standard RDF triples, graphs, and
>>>>>> datasets. </p> ]]
>>>>>> 
>>>>>> Thanks, David
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
> 
>