On 10/1/14, 3:59 AM, Antoine Isaac wrote:
> Hi Tom,
>
> The requirement of not hijacking existing formal specification languages
> for expressing constraints that rely on different semantics has not been
> raised yet.
No, actually, as Tom says below, I raised that point yesterday in the
meeting. Rather clearly, I believe.
>
> In fact the discussions in the RDF-Shapes group showed that for a
> significant part of the RDF community, it doesn't matter. They just
> re-use the OWL syntax with closed world semantics.
I would not characterize it that way. There is *a* group that favors
re-using OWL syntax, led by Kendall Clarke. There is another group that
favors using SPARQL (primarily in the form of SPIN). Each of these,
unfortunately, has a "dog in the fight" -- that is, each has a product
they are selling that uses that technique. And because these are the
validators that are currently available, people use them. Yet I can
point to examples where this causes significant problems (Tom and I will
present some in Austin).
In an attempt at neutrality, EricP (sorry, can't spell his last name :(
) has proposed a third way, shape expressions, ShEx. Shape expressions
*could be* similar to the DSP, in that it could be a way to define
constraints locally that are parallel to, but do not interfere with, the
RDF or OWL semantics of the vocabulary.
Another important point: that group is focused solely on data
validation. Data validation by itself is not an application profile.
>
> I am not comfortable with it either, but ultimately we can't really
> overrun whatver the RDF Shape group decides to be acceptable.
> I'd be in favour of raising it, but rather as an issue, or a desirable
> design principle, rather than a formal requirement.
Like Tom, I think it is THE formal requirement. And since the ShEx group
has not yet met, we do not know what they will decide. Also, they are
contending with commercial interests inside the group, and we do not
have that constraint. I think we can lead by example here, since we
already have the DSP. If we can develop a test suite for the DSP, modify
any areas that need modification, AND provide an easy way for people to
create simple APs, then I think we will have created the "Dublin Core"
for people entering into the linked data world, in the way that Dublin
Core elements were an entry into machine-readable metadata.
kc
>
> Cheers,
>
> Antoine
>
> On 10/1/14 12:34 PM, Thomas Baker wrote:
>> On Tue, Sep 30, 2014 at 11:05:08AM -0700, Karen Coyle wrote:
>>> https://meetings.webex.com/collabs/meetings/playRecording?recordID=12797906&meetingInstanceID=ICWDUC9I93MGCE3CLXLPUZVPSX-JV0D
>>>
>>
>> I tried to join yesterday -- it was 23:00 here in Seoul -- but couldn't
>> get a WebEx connection after five attempts. I did however get a chance
>> to listen to the recording today. I'm sorry I couldn't be there live,
>> because I'm trying to catch up with the discussion, and apologies in
>> advance if the points I make have already been discussed and decided.
>>
>> Apart from the glitch that addresses do not know people, the DSP demo
>> was very nice! However, I get very uneasy when I see OWL2 axioms being
>> treated as "constraints" in a DSP sense (i.e., interpreted according to
>> CWA). I agree with Karen, if I correctly understood her point, that
>> this is "dangerous territory".
>>
>> On the call, that discussion was postponed for a later date, but I look
>> forward to having that discussion as soon as possible because I think it
>> is fundamental.
>>
>> As I see it, the whole question of how a constraint language relates to
>> RDF vocabularies and ontologies is one of the most important and basic
>> _requirements_ for the constraint language itself. The requirement is
>> that a constraint language not replace (or "hijack") the original
>> semantics of properties used in the data. I get uneasy, for example,
>> when OWL cardinality axioms are treated as "constraints" according to a
>> closed-world, unique-name assumption, or by using rdfs:domain or range
>> axioms as if they were expressing mandatory graph patterns.
>>
>> In my recollection, the difference in meaning between "domain as a means
>> of enabling inference" (the OWL sense) and "domain as a way to bind
>> properties to classes" was a source of confusion when the Schema.org
>> vocabulary first appeared, because the early, now-deprecated
>> representations of the Schema.org vocabulary in OWL translated
>> Schema.org domains as rdfs:domain, whereas the Schema.org data model now
>> makes clear that a much looser definition is intended -- one that has
>> more to do with documenting intention than with enabling inference [1]:
>>
>> We have a set of properties:
>>
>> each property may have one or more types as its domains. The
>> property may be used for instances of any of these types.
>>
>> each property may have one or more types as its ranges. The
>> value(s) of the property should be instances of at least one
>> of these types.
>>
>> Has it been proposed to express as a requirement, alongside the other
>> requirements, the notion that the constraint language not impose an
>> alternative interpretation on existing semantics?
>>
>> Tom
>>
>> [1]
>> http://wiki.dublincore.org/index.php/RDF-Application-Profiles/ExamplesFormalConstraints#R-25-OBJECT-PROPERTY-DOMAIN
>>
>> [2] http://schema.org/docs/datamodel.html
>>
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|