W3C home > Mailing lists > Public > public-rdf-comments@w3.org > May 2013

Re: Signal for semantic extensions

From: Pat Hayes <phayes@ihmc.us>
Date: Sun, 19 May 2013 20:10:50 -0500
Cc: Richard Cyganiak <richard@cyganiak.de>, David Booth <david@dbooth.org>, public-rdf-comments <public-rdf-comments@w3.org>
Message-Id: <E6729EC8-8276-455F-8222-CDDA863585EB@ihmc.us>
To: Sandro Hawke <sandro@w3.org>

On May 18, 2013, at 9:46 AM, Sandro Hawke wrote:

> Richard Cyganiak <richard@cyganiak.de> wrote:
>> David,
>> (Unofficial response to ask for clarification)
>> Given that any RDF vocabulary is a semantic extension, isn't the answer
>> here simply that if a client sees a class or property IRI that it
>> doesn't know, then it must assume that additional inferences are
>> possible?
> +1
> It may turn out in some cases that consumers can inspect (including dereference) unknown terms and learn what inferences are possible.   That would be nice, but I don't think we quite know how to do that with a guarantee of completeness yet.

(Also unofficial)

Well, forget about a guarantee of completeness. I think most people don't really want logical completeness in any case (do you really want to know all RDFS tautologies?) But David does have a point. I think that just relying on recognizing IRIs is going to work now and for a while, but it is going to fall apart eventually. FOAF for example uses sameAs and functionalProperty from OWL, and that works because those have a clear semantics that can be extracted from the OWL spec and used in isolation from the rest of OWL. But when things get more complicated, with rule languages for example, this neat extractability of part of an extended vocabulary isn't always going to be well-defined. 

Using something similar to owl:imports to provide a context mechanism in RDF is a neat, simple, device which would handle this and also provide an nice path for future extensions, but this WG is definitely not going to adopt it. Maybe at some time in the future...


> I'd probably argue against a 'requires' thing as too error prone and not really necessary.
>   - Sandro
>> Richard
>> On 18 May 2013, at 04:05, David Booth <david@dbooth.org> wrote:
>>> This comment raises an issue that is somewhat theoretical at present.
>> I mentioned it over a year ago (message below) but have not seen any
>> discussion about it.  I have not seen it be a problem in practice yet,
>> so I do not think it is urgent for the working group to address.  But
>> if RDF gains popularity over the coming years, and more semantic
>> extensions are introduced, it could become a practical consideration,
>> given the long time span between RDF versions.
>>> At present there is no standard way in RDF to unambiguously signal
>> the expectation of a particular semantic extension.  I'll explain
>> further what I mean, and make a specific proposal.  Perhaps others will
>> think of a better way to solve the problem, but hopefully this will at
>> least explain what it is.
>>> Suppose an RDF consumer receives a graph written by an RDF author and
>> (roughly speaking) the RDF consumer wants to be able to fully
>> "understand the author's intended meaning" of that graph.  More
>> precisely, the RDF author has used certain semantic extensions that
>> imply certain entailments, and wishes to allow consumers of that graph
>> to be able to automatically (by machine) determine these entailments.
>> In turn, the RDF consumer wishes to be able to compute all of those
>> entailments.  Note that this is *not* suggesting that the RDF consumer
>> be *required* to compute the RDF author's intended entailments.  It is
>> only about *enabling* the RDF consumer to do so if desired.
>>> For semantic extensions that are well known, such as OWL, the RDF
>> consumer can detect the presence of well known URIs (such as OWL
>> predicates) to know that those well known semantic extensions are
>> intended.  But for semantic extensions that are *not* well know --
>> non-standard semantic extensions -- the RDF consumer has no standard
>> automatable way to know that certain URIs are intended to signal the
>> use of particular semantic extensions.  Thus, the RDF consumer has no
>> standard way of determining whether or not he/she/it has computed all
>> of the entailments that the RDF author intended to convey.
>>> When the RDF consumer processes an RDF graph, the processor should be
>> able to clearly indicate to the user either: "I have computed all of
>> the author's intended entailments" or "I cannot compute all of the
>> author's intended entailments because I do not have the module for
>> semantic extension 'http://example/BobsFavoriteExtension'.  Please load
>> it and try again."  But this is only possible if the RDF author has an
>> unambiguous standard way to signal the intended semantic extensions.
>>> The motivation for this use case is to enable the vision of the
>> semantic web to work, even in the presence of new semantic extensions. 
>> This means that: (a) the RDF consumer cannot be expected to have any
>> other communication with the RDF author (other than obtaining the graph
>> that the author had provided); and (b) the RDF consumer must be able to
>> perform these steps automatically (by machine).
>>> I suggest the RDF working group define a standard predicate
>> rdf:requires (or whatever name the group chooses) that an RDF author
>> can use to indicate that a particular semantic extension is intended. 
>> It could be used like this:
>>> <> rdf:requires <http://example/BobsFavoriteExtension> .
>>> which would indicate that the current document uses semantic
>> extension <http://example/BobsFavoriteExtension> .  Hence, to be
>> assured of determining all of the document author's intended
>> entailments, the RDF processor must understand that semantic extension.
>>> Furthermore, for backward compatibility with OWL, it would be good to
>> define:
>>> owl:imports rdfs:subPropertyOf rdf:semanticExtension .
>>> and recommend that RDF processors also recognize owl:imports as
>> signaling a semantic extension.
>>> Again, since I have not yet seen this issue arise in practice, I
>> would consider it a low priority to fix, and would not mind if the
>> working group decides to defer it to a future RDF version.  On the
>> other hand, it is a very easy gap to fix.
>>> Thanks,
>>> David
>>> On 03/30/2012 06:18 PM, David Booth wrote:
>>>> -------- Forwarded Message --------
>>>> From: David Booth <david@dbooth.org>
>>>> To: Pat Hayes <phayes@ihmc.us>
>>>> Cc: Jonathan A Rees <rees@mumble.net>, Jeni Tennison
>>>> <jeni@jenitennison.com>, www-tag@w3.org List <www-tag@w3.org>
>>>> Subject: Re: The TAG Member's Guide to ISSUE-57 Discussion - F2F
>> reading
>>>> Date: Fri, 30 Mar 2012 18:17:06 -0400
>>>> Hi Pat,
>>>> On Wed, 2012-03-28 at 14:24 -0500, Pat Hayes wrote:
>>>>> FWIW, I am willing to work actively (on- or off-list) with anyone
>> who
>>>>> wants to try reconciling any proposal with the RDF semantics, or
>> just
>>>>> to explore any semantic issues. This is particularly timely as the
>>>>> RDF2 WG is right now debating issues which impinge on the RDF
>>>>> semantics framework, so it would be good to get any pending issues
>> or
>>>>> problems out into the open.
>>>> I would suggest that the RDF WG look at Part 3 "Determining Resource
>>>> Identity" of "Resource Identity and Semantic Extensions: Making
>> Sense of
>>>> Ambiguity":
>>>> http://dbooth.org/2010/ambiguity/paper.html#part3
>>>> That section proposes a standard process for determining resource
>>>> identity.  As far as I know, I did not invent this process.  I
>> simply
>>>> documented what seemed to be the general ideas floating around.
>>>> However, I did identify one specific gap in the RDF specs:
>>>> [[
>>>> At present there is a minor gap in the RDF standards, in that there
>> is
>>>> no standard way for an RDF processor to recognize that a particular
>> URI
>>>> is intended to signal an opaque semantic extension: the knowledge of
>>>> which URIs are intended to signal opaque semantic extensions must be
>>>> externally supplied to the RDF processor.  The RDF processor must
>>>> magically know about them in advance.  It cannot alert the user to
>> the
>>>> need for a new opaque semantic extension that was previously
>> unknown.
>>>> This gap could be addressed by defining a standard predicate, such
>> as
>>>> rdf2:requires, to explicitly indicate when a particular semantic
>>>> extension is required.  However, since it currently seems unlikely
>> that
>>>> many semantic extensions will be needed that cannot be defined using
>>>> standard inference rules, this does not seem like a major gap.
>>>> ]]
>>>> I will forward this message separately to the RDF comments list,
>> since I
>>>> cannot post to the regular RDF list.
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 20 May 2013 01:11:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:33 UTC