Re: [lyo-dev] dcterms:identifier or oslc:shortId (Jean-Luc Johnson)

["Nicholas Crossley" <nick_crossley@xxxxxxxxxx>]

Agreed. And note that OSLC started using
Dublin Core very early, and DC wording has been tightened up in the years
since OSLC first started - for example, some terms now say the values should
be URIs, but in early days that statement did not exist, and OSLC used
strings. dcterms:type is one example of that.

Nick



From:      
 "Jim Amsden"
<jamsden@xxxxxxxxxx>
To:      
 Lyo project developer
discussions <lyo-dev@xxxxxxxxxxx>
Date:      
 06/06/2018 08:16 AM
Subject:    
   Re: [lyo-dev]
dcterms:identifier or oslc:shortId (Jean-Luc Johnson)
Sent by:    
   lyo-dev-bounces@xxxxxxxxxxx

---

Jad,
I think the distinction between the Dublin Core and OSLC definition of
dcterms:identifier is that OSLC is specifying the context in which the
property has intended meaning for OSLC. So these seem consistent to me.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:        Jad
El-Khoury <jad@xxxxxx>
To:        Lyo
project developer discussions <lyo-dev@xxxxxxxxxxx>
Date:        06/06/2018
03:50 AM
Subject:        Re:
[lyo-dev] dcterms:identifier or oslc:shortId (Jean-Luc Johnson)
Sent by:        lyo-dev-bounces@xxxxxxxxxxx

---

Thanks Nick & Jean-Luc,
 
Good input.
 
This however lead to another related question that has been bugging me
for some time. In short, vocabulary vs shape definitions.
 
OSLC 3.0 provides its own description of dcterms:identifier (http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/csprd03/part7-core-vocabulary/oslc-core-v3.0-csprd03-part7-core-vocabulary.html#anyProperties),
namely
“A unique identifier for a resource. Typically read-only and assigned
by the service provider when a resource is created. Not typically intended
for end-user display.”
 
Yet, it is defined already under dcterms (http://dublincore.org/documents/dcmi-terms/#terms-identifier)
as
                “An unambiguous
reference to the resource within a given context.”
 
Unless one is extending the vocabulary terms, why is OSLC 3.0 providing
another explanation?
I can understand if oslc3.0 is to explain the shape/constraints of using
dcterms:identifier – for a particular domain or resource shape. But this
is currently specified as a vocabulary term.
 
I guess this is a question to the Core committee as well
 
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@xxxxxx,
www.kth.se
 
From: lyo-dev-bounces@xxxxxxxxxxx [mailto:lyo-dev-bounces@xxxxxxxxxxx]
On Behalf Of Nicholas Crossley
Sent: 01 June 2018 17:59
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] dcterms:identifier or oslc:shortId (Jean-Luc
Johnson)
 
Note that the 3.0 vocabularies & shapes clarify the OSLC 2.0 intent:
dcterms:identifier is not necessarily human-readable - it might be a GUID
- while oslc:shortId should be human-readable - such as a sequence number.

Personally, I'd steer clear of defining and using a subproperty, since
that just adds complexity that might not be needed.

Nick.



From:        "JOHNSON,
Jean Luc" <jean-luc.johnson@xxxxxxxxxx>
To:        "lyo-dev@xxxxxxxxxxx"
<lyo-dev@xxxxxxxxxxx>
Date:        06/01/2018
07:39 AM
Subject:        Re:
[lyo-dev] dcterms:identifier or oslc:shortId (Jean-Luc Johnson)
Sent by:        lyo-dev-bounces@xxxxxxxxxxx

---

Hello Jad,

The easiest solution would be dcterms:identifier. oslc:shortId value type
is STRING and it is described as a shorter form of dcterms:identifier.

Let's go beyond and let's study the business process implemented in your
application!
Does your property need to be published to external application? You specified
that it is for internal usage. 

So I guess the answer is no. Then you could create your own namespace with
your specific property. 

Do you need to publish this property for external applications to consume
it? I would say no!

Using your private property should not hinder your application interoperability.

Your concern looks quite similar to http://jazz.net/ns/rm#primaryTextwhich
was used by IBM to represent a concept very close to dcterms:description
for the Requirement resource. 

Cordialement, Best regards,
--------------------------------
Jean-Luc Johnson
 


-----Message d'origine-----
De : lyo-dev-bounces@xxxxxxxxxxx[mailto:lyo-dev-bounces@xxxxxxxxxxx]
De la part de lyo-dev-request@xxxxxxxxxxx
Envoyé : vendredi 1 juin 2018 15:11
À : lyo-dev@xxxxxxxxxxx
Objet : lyo-dev Digest, Vol 76, Issue 1

Send lyo-dev mailing list submissions to
               lyo-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
               https://dev.eclipse.org/mailman/listinfo/lyo-dev
or, via email, send a message with subject or body 'help' to
               lyo-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
               lyo-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific than
"Re: Contents of lyo-dev digest..."


Today's Topics:

 1. dcterms:identifier or oslc:shortId (Jad El-Khoury)
 2. Re: dcterms:identifier or oslc:shortId (Jim Amsden)
 3. Re: dcterms:identifier or oslc:shortId (Andrii Berezovskyi)


----------------------------------------------------------------------

Message: 1
Date: Fri, 1 Jun 2018 09:58:41 +0000
From: Jad El-Khoury <jad@xxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: [lyo-dev] dcterms:identifier or oslc:shortId
Message-ID: <3fe68db0cdab4e399f237c6f34282144@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Hi

I need to have a property that uniquely identifies a resource, which is
not its URI (for internal usage, so it is easy to map the resource URI
to the internal database key).

Any tips on a standard RDF property for such a property?

from http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA,
I can see either dcterms:identifier or oslc:shortId.

Is there a reason NOT to use dcterms:identifier, which to me seems more
common/standard.

One argument is that dcterms:identifier is expected to "identify the
resource by means of a string conforming to a formal identification system".
that is, unless you have a such a "formal system" (in my understanding
a database key is not), dcterms:identifier is not appropriate.

regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellv?gen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45 jad@xxxxxx<mailto:jad@xxxxxx>,
https://www.kth.se/profile/jad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/lyo-dev/attachments/20180601/ebc69e72/attachment.html>

------------------------------

Message: 2
Date: Fri, 1 Jun 2018 09:00:06 -0400
From: "Jim Amsden" <jamsden@xxxxxxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] dcterms:identifier or oslc:shortId
Message-ID:
               <OF4450B6E9.5A82942C-ON8525829F.00407DF3-8525829F.00476B66@xxxxxxxxxxxxxxxxxxxxxxx>
               
Content-Type: text/plain; charset="utf-8"

dcterms:identifier

Jim Amsden, Senior Technical Staff Member OSLC and Linked Lifecycle Data
919-525-6575




From:   Jad El-Khoury <jad@xxxxxx>
To:     Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date:   06/01/2018 05:58 AM
Subject:        [lyo-dev] dcterms:identifier or oslc:shortId
Sent by:        lyo-dev-bounces@xxxxxxxxxxx



Hi

I need to have a property that uniquely identifies a resource, which is
not its URI (for internal usage, so it is easy to map the resource URI
to the internal database key).

Any tips on a standard RDF property for such a property?

from http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA,
I can see either dcterms:identifier or oslc:shortId.

Is there a reason NOT to use dcterms:identifier, which to me seems more
common/standard.

One argument is that dcterms:identifier is expected to ?identify the resource
by means of a string conforming to a formal identification system?.
that is, unless you have a such a ?formal system? (in my understanding
a database key is not), dcterms:identifier is not appropriate. 

regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellv?gen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45 jad@xxxxxx,
https://www.kth.se/profile/jad_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/lyo-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/lyo-dev/attachments/20180601/ee061034/attachment.html>

------------------------------

Message: 3
Date: Fri, 1 Jun 2018 13:10:56 +0000
From: Andrii Berezovskyi <andriib@xxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Subject: Re: [lyo-dev] dcterms:identifier or oslc:shortId
Message-ID: <DA0DD2EB-2B3A-43F0-9494-60512C25E29A@xxxxxx>
Content-Type: text/plain; charset="utf-8"

I would consider defining a new ABCorp:primaryKey property as a subproperty
of dcterms:identifier. This will give the necessary semantics for your
code to understand it is dealing with a primary key of the ABCorp. If not
enough, you can also define a new resource ABCorp:TableReference to describe
how one would map the key given in RDF to the right SQL table in the right
DB on the right server.

/Andrew

Den 2018-06-01  15:00 skrev "lyo-dev-bounces@xxxxxxxxxxx<mailto:lyo-dev-bounces@xxxxxxxxxxx>
p? uppdrag av Jim Amsden" <lyo-dev-bounces@xxxxxxxxxxx<mailto:lyo-dev-bounces@xxxxxxxxxxx>
p? uppdrag av jamsden@xxxxxxxxxx<mailto:jamsden@xxxxxxxxxx>>
f?ljande:

dcterms:identifier

Jim Amsden, Senior Technical Staff Member OSLC and Linked Lifecycle Data
919-525-6575




From:        Jad El-Khoury <jad@xxxxxx>
To:        Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date:        06/01/2018 05:58 AM
Subject:        [lyo-dev] dcterms:identifier or oslc:shortId
Sent by:        lyo-dev-bounces@xxxxxxxxxxx
________________________________



Hi

I need to have a property that uniquely identifies a resource, which is
not its URI (for internal usage, so it is easy to map the resource URI
to the internal database key).

Any tips on a standard RDF property for such a property?

from http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA,
I can see either dcterms:identifier or oslc:shortId.

Is there a reason NOT to use dcterms:identifier, which to me seems more
common/standard.

One argument is that dcterms:identifier is expected to ?identify the resource
by means of a string conforming to a formal identification system?.
that is, unless you have a such a ?formal system? (in my understanding
a database key is not), dcterms:identifier is not appropriate.

regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellv?gen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45 jad@xxxxxx<mailto:jad@xxxxxx>,
https://www.kth.se/profile/jad_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/lyo-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/lyo-dev/attachments/20180601/a2a4b6e5/attachment.html>

------------------------------

_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://dev.eclipse.org/mailman/listinfo/lyo-dev

End of lyo-dev Digest, Vol 76, Issue 1
**************************************
The information in this e-mail is confidential. The contents may not be
disclosed or used by anyone other than the addressee. Access to this e-mail
by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately
and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness
of this e-mail as it has been sent over public networks. If you have any
concerns over the content of this message or its Accuracy or Integrity,
please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus
scanning software but you should take whatever measures you deem to be
appropriate to ensure that this message and any attachments are virus free.

_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev


_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev

_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev