Re: fundamental issues

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Hi Peter,
> 
> Thanks for compiling this list. I found it helpful. I have a few
> questions for clarification inline.
> 
>> On 12 Feb 2015, at 22:19, Peter F. Patel-Schneider
<pfpschneider@gmail.com> wrote:
>> 
>> 1. Modelling
>> 
>> Is the working group going to produce a modelling language, i.e., a
>> language that sits alongside RDFS and is used to describe how
>> information in a domain is structured?  The alternative would be to
>> produce a language that takes RDF information that already is
>> potentially subject to a modelling language and determines whether that
>> information satisfies extra conditions.
> 
> I can’t make sense of the distinction that you’re trying to get at here.
> 
> For example, I would not describe Resource Shapes as a modelling 
> language. Yet it can be said to “sit alongside RDFS” and it can be said
> to “describe how information in a domain is structured.”
> 
> Also, is OWL a modelling language in your terminology? It appears to fit
> the “alternative” side of your definition, as it is a language that can
> be said to “take RDF information that already is potentially subject to a
> modelling language (RDFS or the schema.org metamodel)” and “determines
> whether that information satisfies extra conditions”.
> 
> Also, if we didn’t have RDFS and OWL, but had let’s say ShExC, then we 
> certainly could do some modelling with it. ShExC perhaps isn’t a very
> *good* modelling language, but I’m not sure that it’s *not* a modelling
> language.
> 
> How exactly can I tell whether a given language is a modelling language
> or not?
> 
> Or can you explain the distinction you’re trying to get at in a
> different way?

Perhaps "sits alongside" was too polite a description.  Let me make the
message more blunt:

Is the working group going to produce a language that is designed to compete
with RDFS?  Or is the working group going to produce a language that will
work with RDFS ontologies?

>> 2. Target Data
>> 
>> Is the working group producing a solution tailored for RDF data, where
>> RDF graphs and rdf:type are important; for RDFS data, where
>> rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain, and rdfs:range are
>> also important;
> 
> Can you be more clear on what you mean by “important” here? I know what
> kind of data I want to use shapes on, and all of the above predicates
> swirl around somewhere in the vicinity of that data, but how do I know if
> that makes the predicates important?

In RDF and RDFS there are certain predicates that are the most important,
because they have built-in meaning or provide the basis of the language.  In
RDFS it is obvious that these predicates include rdfs:subClassOf,
rdfs:subPropertyOf, rdfs:domain, and rdfs:range. In RDF, the situation is a
little bit more murky, but I claim that rdf:type is the most important
predicate in RDF.   I would be very astonished if rdf:type was not the
most-used predicate in RDF.  rdf:type is the only RDF prediate that has a
short form in RDF syntaxes.

>> for Linked Data, where dereferencing and interlinking is important; or
>> for services data, where brevity may be important?
>> 
>> 2. Shapes and Classes
>> 
>> Are shapes RDF classes, i.e., should shapes be the object of rdf:tyoe 
>> triples, participate in rdfs:subClassOf relationships, and be the
>> object of rdfs:domain and rdfs:range triples?
> 
> I assume by “RDF classes” you mean “RDFS classes”? RDF doesn’t have a 
> built-in notion of classes.

OK.  RDF has the notion of types, via rdf:type.  I took the liberty of
calling this a class.  You could say instead

Are shapes RDF types?

> The question is only sensible if one already assumes RDFS or OWL 
> semantics. Outside of RDFS/OWL semantics, resources can do all these
> things without being classes.

OK, so replace RDF classes with "RDF types in RDF and RDFS classes in
RDFS".  The point is whether documents will contain triples that use shapes
where there are now RDF type or RDFS classes.

>> 3. Shape Scope
>> 
>> What sort of scopes can be given to shapes?  (For example, it is
>> possible to state that a particular node in a graph is governed by a
>> shape?  Or all instances of a particular class in a graph?  Or all
>> nodes in a graph?)
>> 
>> It is possible to state that all nodes in a graph must validate against
>> one of several shapes?  Or that there must exist a node in a graph
>> that validates against a shape?
> 
> I agree that this is an open question, but it doesn’t appear to be a 
> fundamental question that must be resolved before the WG can move on to 
> solutions.

What kinds of scope should there be is an issue that divides the working
group.  People in the working group have had very different reactions to
solutions and requirements I think springing from their differing stances
on this particular issue.  (For example, I think that class-based scope is
going to be the most important so I wasn't bothered by requirements that
uses being an instance of a class as a triggering condition.  However,
people who do not think that class-based scope was the primary scope were
bothered.)   Discussing scope early on will provide better guidance on the
desirabilityy of solutions.

>> 4. Initiating Validation
>> 
>> What are the arguments to validation?  It is possible to directly
>> specify scopes and shapes in an invocation of validation or do shapes
>> and scopes have to be encoded in an RDF graph or other document?
> 
> I fail to understand why you consider this question important. Sure, the 
> spec could be written either way, but what other decisions before the WG 
> depend on this?

My view here is that this is an important aspect of the specification.  This
issue may not need to be determined so early, but it has caused some
confusion in the evaluation of proposals already.

>> Can validation be triggered by events such as invocation of a web 
>> service or posting by a web service?
> 
> The answer to this is obviously: “Sure.”
> 
> Was the question whether this WG will specify mechanisms to associate
> shapes with web services?

Yes, this would have been a better way of stating the issue.


peter


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU34fSAAoJECjN6+QThfjzXWQH/iKGsNysfWIbjsvt/AW3R+yX
/7iFV4sxM6HfAxnaY/9A8FXaP17MRaO+mIeatlmM8t7t+T2JY6muixO2nkSleRcU
KIcuuvHHMfKc7BjjU/OwQWX52qW1PrA/bOBc+4wPiyPPjBC3S4TRar6sJWet2JzH
fXj+/brF0EU/+jDAjyq7jYPOtAbxE0/Bw7hjpi9sc3ow1O0Jz+8KvAmX+UpXpaZN
U4o8LqEWdVUxzP7C5tCnlL9Zylu3aYbGTxk134QuJ5YBhfA4vE0/tktn6VT3F3+p
FuIgulKTid7fVGrjwBcfonfa3DWUMiw1mZGTIj95o4DXDhp9N46MB4Ox191FTSk=
=hjMs
-----END PGP SIGNATURE-----

Received on Saturday, 14 February 2015 17:37:52 UTC