Re: New DRs

Thanks for this, Stasinos. I know that this is what you've already said
in your previous emails. I've not ignored them in my last messages.
Only, I've thought that it would have helped the discussion if we have
clearly identified the issues to be addressed wrt the specific
components of DRs.

So, let me summarize your considerations wrt what has been said. Please
tell me whether I'm correct or not.

The main problem is: are RDF/OWL the suitable languages to express the
semantics of DRs?

1. The semantics of the statement linking a DR scope with DR
"decriptors" can be expressed by the rdfs:subclassOf property. For this,
we don't need OWL: we just need RDF/RDF Schema

2. The attribution, validity period, and issue date can be expressed by
using either RDF reification or owl:Ontology/foaf:Document. In the
former case, we don't need OWL. Actually, we don't need OWL also in case
we use the latter approach: in fact, foaf:Document is a RDFS class, and
both foaf:Document and owl:Ontology can be expressed (at least,
according to our needs) by the following statement:

<rdf:Description rdf:about="">
  <foaf:maker rdf:resource="http://www.example.org/foaf.rdf#david" />
  <dcterms:issued>2006-12-31</dcterms:issued>
  <wdr:validFrom>2006-12-31</wdr:validFrom>
  <wdr:validUntil>2006-12-31</wdr:validUntil>
</rdf:Description>

3. The DR "descriptors" can be expressed by using a set of RDF/OWL
statements. The reason why OWL has been used is that such class is
defined by using the notion of "restriction", corresponding to
owl:Restriction, but not available in RDF. Can we avoid using
owl:Restriction?

4. The big problem concerns the DR scope, since here we use constraints
concerning URI patterns. I agree that OWL (and also RDF) has not been
built with this purpose. So, which other solutions we have?

About point 4 I have a specific question: provided that RDF/OWL have not
been designed for pattern matching purposes, there exist RDF-based
languages who support it, namely, SWRL and N3. So, why cannot we do the
same?


Andrea


Stasinos Konstantopoulos wrote:
> Hi,
> 
> Please allow me to voice some concerns, TBD at today's telco.
> 
> On Mon Nov 26 09:16:05 2007 Andrea Perego said:
> 
>> First we specify an owl:Class denoting all the resources hosted by
>> example.org (i.e., the "DR's scope"):
>>
>> <owl:Class rdf:ID="ResourceOnExampleDotOrg">
>>   <rdfs:subclassOf>
>>     <owl:Restriction>
>>       <owl:onProperty rdf:resource="&wdr;includeHost" />
>>       <owl:hasValue>example.org</owl:hasValue>
>>     </owl:Restriction>
>>   <rdfs:subclassOf>
>> </owl:Class>
>>
>> Then we specify an owl:Class denoting all the resources which are safe
>> for children (i.e., what formerly was called the "DR's descriptors"):
>>
>> <owl:Class rdf:ID="ResourceSafeForChildren">
>>   <rdfs:subclassOf>
>>     <owl:Restriction>
>>       <owl:onProperty rdf:resource="&icra;oz" />
>>       <owl:hasValue>true</owl:hasValue>
>>     </owl:Restriction>
>>   <rdfs:subclassOf>
>>   <rdfs:subclassOf>
>>     <owl:Restriction>
>>       <owl:onProperty rdf:resource="&icra;vz" />
>>       <owl:hasValue>true</owl:hasValue>
>>     </owl:Restriction>
>>   <rdfs:subclassOf>
>>   [... more stuff ...]
>> </owl:Class>
> 
> I believe you will agree that if OWL vocabulary is used, it should be
> used as prescribed by the OWL specification, rather than using the
> formalism under a different semantics. Although not shown in Andrea's
> example, I remember a strong POWDER desideratum of being able to express
> overridable defaults. Imagine augmenting the example above with the
> following, based one of Phil's examples:
> 
> <owl:Class rdf:ID="ResourceOnExampleDotOrgAssociates">
>   <rdfs:subclassOf>
>     <owl:intersectionOf>
>       <owl:Restriction>
>         <owl:onProperty rdf:resource="wdr:includeHost" />
>         <owl:hasValue>example.org</owl:hasValue>
>       </owl:Restriction>
>       <owl:Restriction>
>         <owl:onProperty rdf:resource="wdr:startsPath" />
>         <owl:hasValue>associates</owl:hasValue>
>       </owl:Restriction>
>     </owl:intersectionOf>
>   <rdfs:subclassOf>
> </owl:Class>
> 
> <owl:Class rdf:ID="ResourceUnSafeForChildren">
>   <rdfs:subclassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&icra;oz" />
>       <owl:hasValue>false</owl:hasValue>
>     </owl:Restriction>
>   <rdfs:subclassOf>
>   <rdfs:subclassOf>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="&icra;vz" />
>       <owl:hasValue>false</owl:hasValue>
>     </owl:Restriction>
>   <rdfs:subclassOf>
>   [... more stuff ...]
> </owl:Class>
> 
> Making ResourceUnSafeForChildren a subclass of
> ResourceOnExampleDotOrgAssociates is going to make a resource like
> http://www.example.org/associates/sample/ match both classes and have
> *two* instatiations of the icra:oz property, one carrying the value
> "true" and one carrying the value "false".
> 
> In general, non-monotonicity (defaults and exceptions) does not fit OWL
> semantics, and that has nothing to do with the computational machinery
> used to infer facts from OWL knowledge bases (DL reasoners, rule
> systems, or whatever) it is a feature of the semantics of OWL itself.
> One can imagine an OWL-prime formalism that does included these
> features, and one can also build tools to support it, but one should
> also specifically say that this is a brand new species, not be confused
> with what semantic web tools identify as OWL. Especially in order to
> satisfy the desideratum that POWDER publishes data in a format that
> won't be misunderstood by existing tools.
> 
> On a related note, on Tue Nov 20 16:59:16 2007 Phil Archer said:
> 
>> We are looking at OWL only because it appears to do what we need -
>> which is to provide a method through which we can publish a definition
>> of, say, 'mobileOK' and a resource set and find out that the resource
>> set is mobileOK. Importantly, it allows us to publish data in a format
>> that won't be misunderstood by existing tools.
> 
> This bit I am not entirely persuaded about; OWL appearing to do what
> POWDER needs, that is. URI Group membership rules and attribution (in
> their current form) do not fit into OWL, and that only leaves us with
> the mapping between URI groups and descriptors.
> 
> This latter aspect fits into OWL, but not perfectly, as, at least
> according to the current use cases, OWL is too powerful for the simple
> needs of this particular mapping. POWDER still can choose to keep OWL as
> part of the powder schema, as long as it is clear to POWDER that there
> is a lot of expressivity left untapped. Furthermore, POWDER tools have
> to realize that they might encounter complex OWL constructs, and know
> how to deal with them.
> 
>> The foaf:maker attribute is critical! Without it, POWDER isn't POWDER.
>>
>>> IF 3 or more authories say it is ChildSafe
>>> THEN it is ReallyChildSafe
>> That's a rule that an implementor might define and use but it's beyond
>> the scope of POWDER. What we're about it providing the data that can
>> be used in rules, whether written in a semantically-rich environment
>> or just a straightforward Boolean statement.
> 
> POWDER has to specify what kinds of constructs are supported and what
> aren't. You shouldn't think of this as an implementation detail, this
> is a representation issue, determining the form that DR rules take.
> 
> Supporting or not axioms like this is going to delineate the
> boundaries of the expressivity required by the POWDER formalism. The
> usual trade-off of simplicity vs. expressivity applies, so the more
> complex things the labelling authority can say, the more demanding is
> the formalism going to be on the child-protection expert writing the
> rules.
> 
>> Now, about the issue raised by Stasinos about DR representation.
>>
>> In theory, a DR can be specified by using any suitable (knowledge
>> representation) language. However, the purpose of POWDER is to provide
>> specifications explaining how they can be expressed by using Web
>> technologies. So, we have three options:
>> - using XML
>> - using RDF/OWL
>> - using a Semantic Web rule language
> 
> RDF/OWL is one particular RDF schema, but not the only one. POWDER can
> define another RDF schema, which is not OWL. As a matter of fact,
> given the various constraints in place, it seems that POWDER can only
> be some (not OWL) RDF schema.
> 
>> As a matter of fact, it has been noticed that the semantics of a DR is
>> equivalent to a rule of the type "IF a resource is hosted by example.org
>> THEN it is safe for children." So, rule languages should be the right
>> choice. The problem is that, at the moment, there do not exist
>> *standard* rule languages (N3 and SWRL are just proposals), and so we
>> cannot use them.
>>
>> XML may be fine, but the problem is that it is meant for representing
>> data structures, and cannot express the semantics of a DR.
> 
> RDF is a semantics for XML, that of sets of predicate-subject-object
> triples. OWL is a semantics for RDF, that of dyadic first-order logic.
> In other words:
> (a) all valid RDF documents are also valid XML documents. The reverse
>     is not necessarily true.
> (b) all valid OWL documents are also valid RDF documents. The reverse
>     is not necessarily true.
> 
> I think of POWDER as an RDF schema (specifying syntax), and a
> document+reference implementation giving semantics to RDF documents that
> comply to the POWDER schema. The question is whether OWL vocabulary will
> be used for parts of POWDER documents.
> 
> Going back to today's email by Andrea:
> 
>> The next step concerns how we can specify that such claim has been made
>> by David.
>>
>> [snipped reification example and explanation]
>>
>> Now, the first point is: does anybody agree that this is the correct way
>> of expressing the semantics of a DR by using RDF/OWL?
> 
> Using OWL Full, as this is a second-order construct. Note that the new
> OWL-1.1 specification will only allow second-order
> constructs if they are treated as extra-logical annotations, and not
> participate in any concept descriptions.
> Quoting http://www.w3.org/Submission/owl11-overview/#2.4 :
> 
>> In OWL 1.1 a name can be used as any or all of an individual, a class,
>> or a property. The computational problems that would arise if this
>> were treated as in RDF are avoided by ensuring that no aspect of the
>> use of the name as an individual has any effect on the meaning of the
>> name as a class.
> 
> This is why I insisted on discussing what kinds of constructs foaf:maker
> properties will be allowed to participate in. This is not an
> implementation detail, this is crucial for determining the expressivity
> of the formalism being defined.
> 
> Best,
> Stasinos

Received on Monday, 26 November 2007 14:32:59 UTC